Python 2 vs python 3 debate
On Tue, Dec 16, 2014 at 10:31:04AM -0500, William Muriithi wrote:
<html><head><meta http-equiv="Content-Type" content="text/plain;"><style> body { font-family: "Calibri","Slate Pro","sans-serif"; color:#262626 }</style> </head> <body data-blackberry-caret-color="#00a8df"><div>Morning, </div><div><br></div><div>Last week on Monday, Hugh listed a list of talks that were to take place following Tuesday though that didn't happen. There was a scheduled talk.</div><div><br></div><div>I did note though he raised the issue of how entrenched python 2 is. I am on python list and boy, that debate has been in the second week now.</div><div><br></div><div>http://www.mail-archive.com/python-dev@python.org/msg85353.html</div><div><br></div><div>http://www.mail-archive.com/python-dev@python.org/index.html#85319</div><div><br></div><div>What I find odd is how some of the devs there misjudge the need of distribution support. In most companies, installing two versions of python is none starter, so don't see python 3 being widespread until after two release of Redhat with python 3 native support. Two releases as most people are still on RHEL5 and RHEL6 for example.</div><div><span style="font-family: Calibri, 'Slate Pro', sans-serif;"><br></span></div><div><span style="font-family: Calibri, 'Slate Pro', sans-serif;">That may be around 2020 and hence a little early to invest in python 3 scripts.</span></div><div><span style="font-family: Calibri, 'Slate Pro', sans-serif;"><br></span></div><div><span style="font-family: Calibri, 'Slate Pro', sans-serif;">William </span></div><div><br></div><div></div></body></html>
Please no HTML crap. Major demangling done by hand below:
Morning,
Last week on Monday, Hugh listed a list of talks that were to take place following Tuesday though that didn't happen. There was a scheduled talk. I did note though he raised the issue of how entrenched python 2 is. I am on python list and boy, that debate has been in the second week now. http://www.mail-archive.com/python-dev@python.org/msg85353.html http://www.mail-archive.com/python-dev@python.org/index.html#85319
What I find odd is how some of the devs there misjudge the need of distribution support. In most companies, installing two versions of python is none starter, so don't see python 3 being widespread until after two release of Redhat with python 3 native support. Two releases as most people are still on RHEL5 and RHEL6 for example. That may be around 2020 and hence a little early to invest in python 3 scripts.
Well certainly Debian has no issue installing both python 2 and 3 at the same time and has done so for quite a while. Next release appears to have 2.7 and 3.4 installed. It is rather annoying when languages stop supporting existing working code. To me that pretty much means the language is immature and perhaps even badly managed. Not that that has ever stopped a language from becoming popular. -- Len Sorensen
On Tue, Dec 16, 2014 at 12:01:07PM -0500, James Knott wrote:
On 12/16/2014 11:57 AM, Lennart Sorensen wrote:
Please no HTML crap. Major demangling done by hand below:
Some mail lists automagically block HTML messages. Could that not be done on this one?
Good question. I imagine someone knows the answer. -- Len Sorensen
| From: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> | | On Tue, Dec 16, 2014 at 10:31:04AM -0500, William Muriithi wrote: | | Please no HTML crap. Major demangling done by hand below: Thanks. | > Last week on Monday, Hugh listed a list of talks that were to take place | > following Tuesday though that didn't happen. "were to take place" is too strong. I put forward some ideas to try to make an empty spot more interesting (in no official capacity!). It turned out that the spot wasn't empty. That's a good thing. What was empty was the meeting announcement on the web page. Not so good. | > I did note though he raised the issue of how entrenched python 2 is. I | > am on python list and boy, that debate has been in the second week now. I'm not much of a Python user. I'm certainly not too aware of things in its ecosystem. I think that it is good that language powers-that-be consider incompatible updates. Otherwise mistakes are with us forever. They should be infrequent and probably batched. It helps a lot if the incompatibility can be mechanically cleansed. Second best: mechanically detected statically. Third best: mechanically detected dynamically. Horrible: just behaving different at runtime. At some point, the community has to go cold turkey. No new work on libraries etc. for the old thing. It's like taking off a bandaid: net pain is less if the transition is quick. Of course some kind of synchronization would be useful. What better use of a BDFL. | > What I find odd is how some of the devs there misjudge the need of | > distribution support. In most companies, installing two versions of | > python is none starter, so don't see python 3 being widespread until | > after two release of Redhat with python 3 native support. Two releases | > as most people are still on RHEL5 and RHEL6 for example. | > That may be around 2020 and hence a little early to invest in python | > 3 scripts. RHEL5 and RHEL6 have very long support cycles. It is unreasonable to claim those as requirements. In fact, they are designed to be stable. Doing new development on and for them is kind of a contradiction. OK, I admit that until 7.1 is out, maybe 6 can be defended. Fedora 20 seems to have Python 2.7.5 and 3.3.2. Centos 6.6 only has python 2.6.6 Centos 5.11 only has Python 2.4.3 This speaks to how much RHEL values stability. Perhaps Python routinely and frequently breaks compatibility and that's why these old versions hang around. BTW I consider the stability of RHEL (or Windows) a bit of a problem. Perhaps our way out is virtual machines or containerization. They change coupling. I don't really like that. | It is rather annoying when languages stop supporting existing working | code. To me that pretty much means the language is immature and perhaps | even badly managed. Not that that has ever stopped a language from | becoming popular. There are so many language mistakes frozen in amber. How long did C keep "int" is the default type if you neglect to mention a type in a declaration? This should have been a compile-time diagnosed error decades ago. How long did FORTRAN allow undeclared variables? I don't understand what's so hard about the Python 2 => 3 transition. Is it too big a step? Are there not enough attractions? Is the first step a lulu[1]? [1] phrase is perhaps out of date but you can see it at the end of <http://www.dailymotion.com/video/x48aud_merrie-melodies-jack-wabbit-and-the_shortfilms>
On Tue, Dec 16, 2014 at 01:06:19PM -0500, D. Hugh Redelmeier wrote:
| From: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> | | On Tue, Dec 16, 2014 at 10:31:04AM -0500, William Muriithi wrote: | | Please no HTML crap. Major demangling done by hand below:
Thanks.
I do not intend to make a habit of it, but the question actually seemed interesting enough to bother.
| > Last week on Monday, Hugh listed a list of talks that were to take place | > following Tuesday though that didn't happen.
"were to take place" is too strong. I put forward some ideas to try to make an empty spot more interesting (in no official capacity!). It turned out that the spot wasn't empty. That's a good thing.
What was empty was the meeting announcement on the web page. Not so good.
It was a bit confusing.
| > I did note though he raised the issue of how entrenched python 2 is. I | > am on python list and boy, that debate has been in the second week now.
I'm not much of a Python user. I'm certainly not too aware of things in its ecosystem.
I think that it is good that language powers-that-be consider incompatible updates. Otherwise mistakes are with us forever. They should be infrequent and probably batched.
Well that does seem to be mostly the case with python 3. I am still very very very disappointed that they did NOT remove the broken and essentially useless lambda support so that they could some day replace it with a working one. Python likes to make it seem like you can do functional (rather than procedural) code in it, and then when you try it goes "ha ha, fooled you".
It helps a lot if the incompatibility can be mechanically cleansed. Second best: mechanically detected statically. Third best: mechanically detected dynamically. Horrible: just behaving different at runtime.
At some point, the community has to go cold turkey. No new work on libraries etc. for the old thing. It's like taking off a bandaid: net pain is less if the transition is quick. Of course some kind of synchronization would be useful. What better use of a BDFL.
Well as long as they make it easy to keep around an older version for handling old code.
| > What I find odd is how some of the devs there misjudge the need of | > distribution support. In most companies, installing two versions of | > python is none starter, so don't see python 3 being widespread until | > after two release of Redhat with python 3 native support. Two releases | > as most people are still on RHEL5 and RHEL6 for example. | > That may be around 2020 and hence a little early to invest in python | > 3 scripts.
RHEL5 and RHEL6 have very long support cycles. It is unreasonable to claim those as requirements. In fact, they are designed to be stable. Doing new development on and for them is kind of a contradiction. OK, I admit that until 7.1 is out, maybe 6 can be defended.
It is rather unreasonable how some people insist on stability above all else, which means not changing things, and then at the same time complain that new features are missing.
Fedora 20 seems to have Python 2.7.5 and 3.3.2. Centos 6.6 only has python 2.6.6 Centos 5.11 only has Python 2.4.3
This speaks to how much RHEL values stability.
Perhaps Python routinely and frequently breaks compatibility and that's why these old versions hang around.
BTW I consider the stability of RHEL (or Windows) a bit of a problem. Perhaps our way out is virtual machines or containerization. They change coupling. I don't really like that.
| It is rather annoying when languages stop supporting existing working | code. To me that pretty much means the language is immature and perhaps | even badly managed. Not that that has ever stopped a language from | becoming popular.
There are so many language mistakes frozen in amber.
How long did C keep "int" is the default type if you neglect to mention a type in a declaration? This should have been a compile-time diagnosed error decades ago.
But you saved 4 bytes of code each time you didn't specify. Think of the bytes saved.
How long did FORTRAN allow undeclared variables?
I don't understand what's so hard about the Python 2 => 3 transition. Is it too big a step? Are there not enough attractions? Is the first step a lulu[1]?
I think a lot of people rely on libraries for python, and until those are converted to work with the new version, people can't move their own code to the new version.
[1] phrase is perhaps out of date but you can see it at the end of <http://www.dailymotion.com/video/x48aud_merrie-melodies-jack-wabbit-and-the_shortfilms>
-- Len Sorensen
On 12/16/2014 01:06 PM, D. Hugh Redelmeier wrote:
RHEL5 and RHEL6 have very long support cycles. It is unreasonable to claim those as requirements. In fact, they are designed to be stable. Doing new development on and for them is kind of a contradiction. OK, I admit that until 7.1 is out, maybe 6 can be defended.
Fedora 20 seems to have Python 2.7.5 and 3.3.2. Centos 6.6 only has python 2.6.6 Centos 5.11 only has Python 2.4.3
That makes Centos 6.6 and 5.11 pretty much useless for deploying modern Django web applications if we're to rely solely on the distro-supplied Python. Fortunately, there is a relatively easy way to work around that also addresses the Python 2 vs Python 3 issue. We only deploy Python applications using virtualenv <https://virtualenv.readthedocs.org/en/latest/virtualenv.html>, which "is a tool to create isolated Python environments". We can deploy any version of Python we want in that virtualenv and it will be completely isolated from the system-wide Python. This is useful not just for dealing with Python version issues but also library version issues. For instance, we have multiple versions of Django deployed for projects of various vintage. If we relied on the distro-supplied Django package, we'd have to upgrade every Django project at the same time or dedicate a machine, real or virtual, for each Django version, neither of which are viable options. The claim that deploying Python 2 and Python 3 on the same machine is a "non-starter" points to a fundamental lack of understanding of how Python applications are actually deployed. This is really much ado about nothing. -- Regards, Clifford Ilkay Dinamis +1 647-778-8696
D. Hugh Redelmeier wrote:
I'm not much of a Python user. I'm certainly not too aware of things in its ecosystem.
I think that it is good that language powers-that-be consider incompatible updates. Otherwise mistakes are with us forever. They should be infrequent and probably batched.
It helps a lot if the incompatibility can be mechanically cleansed. Second best: mechanically detected statically. Third best: mechanically detected dynamically. Horrible: just behaving different at runtime.
At some point, the community has to go cold turkey. No new work on libraries etc. for the old thing. It's like taking off a bandaid: net pain is less if the transition is quick. Of course some kind of synchronization would be useful. What better use of a BDFL.
If you've got reams of mission-critical legacy code written in the previous version of a language, whether FORTRAN IV or original K&R C or Perl 4 or whatever other deprecated tongue was spoken by the coders of yore, a new system that's going to not run that code or misreinterpret it in interestingly broken ways is _NOT_ going to be your friend (or be of any immediate practical use in production). You do need room to introduce new languages, or improved dialects of existing ones, but there does need to be a way for the versions to coexist, so your Perl 4, 5, and 6 code each go to their own interpreter, or GCC can be flagged to parse according to a particular C standard, and all your old code keeps on happily working. You cannot go and rewrite or mechanically-recode or even recompile everything on some flag day and have perfectly-refactored new code running bug-free by sunset. And if some language's BFDL and TPTB decide that the new version is going to break old code and not support compatibility, the wise coder having to refactor that codebase goes to a different language entirely because that bunch are likely to break everything again next time they have a better idea, and the time after that too. There is room for code-refactoring projects, if new features make the code more maintainable (as if! See also: "technical debt" and having to QA everything again), but they have to run on the downstream timeline and not be dictated by upstream releasing their whizzy new compiler. Ideally there's some legacy maintenance on libraries and such, but there are advantages to a *stable* language where someone isn't going to tweak the meaning or precedence of something or add a new reserved keyword or whatever else might change the meaning of some million-line system that someone doesn't want to refactor.
How long did C keep "int" is the default type if you neglect to mention a type in a declaration? This should have been a compile-time diagnosed error decades ago.
How long did FORTRAN allow undeclared variables?
A compiler running in default mode can't ever reject something that was once a valid program, but undefined variables IMHO were always something that dismerited a warning; maybe declaring the code to be pre-good-taste could silence the warnings, while a later language revision requiring proper declarations could make that an error if that mode is declared.
I don't understand what's so hard about the Python 2 => 3 transition. Is it too big a step? Are there not enough attractions? Is the first step a lulu[1]?
I've done a wee bit of Python, but not tracking it too closely. There are too many languages! I miss the days when knowing C, shell, and awk would cover all you needed for Unix utilities. It seems that nowadays, diving into the source of some random Linux package that needs something checked or tweaked, every other time one finds that yet another different language was used; it's the Tower Of Babel story all over, or if not that then the coding style is something, ahhh, *unique*. It's good that language-design research is still happening, and new languages are getting road-tested, but there's just not the mindspace for any of us to simultanously master them all, and by the time you try there will be another three or so to learn. I'm almost cheering for evolutionary pressure to cross a few of them off the list! [1] legacy footnote not supported in this message. -- Anthony de Boer
On 12/16/2014 05:28 PM, Anthony de Boer wrote:
I've done a wee bit of Python, but not tracking it too closely. There are too many languages!
I hear you! I'm learning Javascript and wondering, "How did this language become so ubiquitous? Why doesn't Python run in browsers? It's a great language for embeddable scripting." -- Regards, Clifford Ilkay +1 647-778-8696
On 2014-12-16 10:36 PM, Clifford Ilkay wrote:
On 12/16/2014 05:28 PM, Anthony de Boer wrote:
I've done a wee bit of Python, but not tracking it too closely. There are too many languages!
I hear you! I'm learning Javascript and wondering, "How did this language become so ubiquitous? Why doesn't Python run in browsers? It's a great language for embeddable scripting."
See http://www.brython.info for an implementation of Python in JS in the browser. Might do what you're after ;) Cheers, Jamon
On 12/17/2014 10:21 AM, Jamon Camisso wrote:
On 2014-12-16 10:36 PM, Clifford Ilkay wrote:
On 12/16/2014 05:28 PM, Anthony de Boer wrote:
I've done a wee bit of Python, but not tracking it too closely. There are too many languages! I hear you! I'm learning Javascript and wondering, "How did this language become so ubiquitous? Why doesn't Python run in browsers? It's a great language for embeddable scripting." See http://www.brython.info for an implementation of Python in JS in the browser. Might do what you're after ;)
Interesting toy but not something I'd rely on to build a serious application right now. For better or worse, AngularJS has huge critical mass and that's where we've cast our lot. -- Regards, Clifford Ilkay +1 647-778-8696
On 2014-12-17 12:42 PM, Clifford Ilkay wrote:
See http://www.brython.info for an implementation of Python in JS …
Interesting toy but not something I'd rely on to build a serious application right now.
Also: Brython 3.0.1 on Netscape 5.0 (X11)
2**100 1
Compare with: $ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
2**100 1267650600228229401496703205376
I'll pass for now. cheers, Stewart
On 18 December 2014 at 09:28, Stewart C. Russell <scruss@gmail.com> wrote:
On 2014-12-17 12:42 PM, Clifford Ilkay wrote:
See http://www.brython.info for an implementation of Python in JS …
Interesting toy but not something I'd rely on to build a serious application right now.
Also:
Brython 3.0.1 on Netscape 5.0 (X11)
2**100 1
Compare with:
$ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information.
2**100 1267650600228229401496703205376
I'll pass for now.
If Netscape 5.0 had ever been released, it would have come out in 1998. I'd be shocked if ANY modern framework functioned in a 16 year old browser: I expect this was a typo. If you mean that it's producing numbers that bad in a modern browser, yes, that's an issue. Could you clarify? -- Giles http://www.gilesorr.com/ gilesorr@gmail.com
On Dec 18, 2014 10:08 AM, "Giles Orr" <gilesorr@gmail.com> wrote:
If you mean that it's producing numbers that bad in a modern browser, yes, that's an issue. Could you clarify?
Sure; that's what's reported in the current Firefox. Chrome also returns 5.0; but also adds some other output to hint it's a newer browser. (Is anyone on this list running a 16 year old browser for anything but tiny embedded system needs or lulz? I used to run the Chimera browser for far longer than strictly necessary as I was an SGML nerd and it supported HTML 3.0, not the vile 3.2) Checking Brython's issues, I see this is flagged. It's doing something unwise with JS's int methods when it should be using bigints. As a brythonic Scot (there aren't that many of us) I would like to approve of this message ... Stewart
On Tue, Dec 16, 2014 at 5:36 PM, Clifford Ilkay <clifford_ilkay@dinamis.com> wrote:
I hear you! I'm learning Javascript and wondering, "How did this language become so ubiquitous? Why doesn't Python run in browsers? It's a great language for embeddable scripting."
The industry seems to like converters (i.e. GWT, Pygamas, etc.) and not replacing JavaScript with projects like IronMonkey. Which is kind of interesting considering there is a huge user base of Python programmers who are coding on top of Microsoft's Excel (instead of having to use VB.NET and C#). CoffeeScript has a Python like syntax (I'm loosely using the word 'like') if you are interested in not having to write JavaScript. But it compiles CoffeeScript into JavaScript so it's not the best thing in the world.
Is there really a need to moderate long-time members of this mailing list? I notice that every message I send is held in the moderator queue and is eventually released. On 12/17/2014 10:35 AM, Myles Braithwaite wrote:
I hear you! I'm learning Javascript and wondering, "How did this language become so ubiquitous? Why doesn't Python run in browsers? It's a great language for embeddable scripting." The industry seems to like converters (i.e. GWT, Pygamas, etc.) and not replacing JavaScript with projects like IronMonkey. Which is kind of interesting considering there is a huge user base of Python
On Tue, Dec 16, 2014 at 5:36 PM, Clifford Ilkay <clifford_ilkay@dinamis.com> wrote: programmers who are coding on top of Microsoft's Excel (instead of having to use VB.NET and C#).
I'd looked at Pyjamas and I was never convinced of its merits. Like Brython that Jamon pointed out, it occurred to me as an interesting toy but not something I'd bet the farm on.
CoffeeScript has a Python like syntax (I'm loosely using the word 'like') if you are interested in not having to write JavaScript. But it compiles CoffeeScript into JavaScript so it's not the best thing in the world.
I don't see the point of CoffeeScript. It removes curly braces and some other constructs at the expense of reducing the number of people who can actually read the code I write. -- Regards, Clifford Ilkay Dinamis +1 647-778-8696
Cliff, the answer to your question is no there is no need, but you seem to keep coming up even after we have given you carte blanche permission. Bill On Wed, Dec 17, 2014 at 12:53 PM, Clifford Ilkay <clifford_ilkay@dinamis.com
wrote:
Is there really a need to moderate long-time members of this mailing list? I notice that every message I send is held in the moderator queue and is eventually released.
On 12/17/2014 10:35 AM, Myles Braithwaite wrote:
I hear you! I'm learning Javascript and wondering, "How did this language become so ubiquitous? Why doesn't Python run in browsers? It's a great language for embeddable scripting." The industry seems to like converters (i.e. GWT, Pygamas, etc.) and not replacing JavaScript with projects like IronMonkey. Which is kind of interesting considering there is a huge user base of Python
On Tue, Dec 16, 2014 at 5:36 PM, Clifford Ilkay <clifford_ilkay@dinamis.com> wrote: programmers who are coding on top of Microsoft's Excel (instead of having to use VB.NET and C#).
I'd looked at Pyjamas and I was never convinced of its merits. Like Brython that Jamon pointed out, it occurred to me as an interesting toy but not something I'd bet the farm on.
CoffeeScript has a Python like syntax (I'm loosely using the word 'like') if you are interested in not having to write JavaScript. But it compiles CoffeeScript into JavaScript so it's not the best thing in the world.
I don't see the point of CoffeeScript. It removes curly braces and some other constructs at the expense of reducing the number of people who can actually read the code I write.
-- Regards,
Clifford Ilkay Dinamis
+1 647-778-8696
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Demo? On 17/12/14 10:35 AM, Myles Braithwaite wrote:
The industry seems to like converters (i.e. GWT, Pygamas, etc.) and not replacing JavaScript with projects like IronMonkey. Which is kind of interesting considering there is a huge user base of Python programmers who are coding on top of Microsoft's Excel (instead of having to use VB.NET and C#).
CoffeeScript has a Python like syntax (I'm loosely using the word 'like') if you are interested in not having to write JavaScript. But it compiles CoffeeScript into JavaScript so it's not the best thing in the world.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Ensure confidentiality, authenticity, non-repudiability iEYEARECAAYFAlSVpqgACgkQuRKJsNLM5eqRFQCfdbDX8Fve4uNuvICQSYGY8RiF N7QAoLCqoNtdDFAVdWmndACBStlnwFzT =vzdj -----END PGP SIGNATURE-----
participants (13)
-
Anthony de Boer -
Bill Thanis -
Bob Jonkman -
Clifford Ilkay -
D. Hugh Redelmeier -
Giles Orr -
James Knott -
Jamon Camisso -
Lennart Sorensen -
Myles Braithwaite -
Stewart C. Russell -
Stewart Russell
-
William Muriithi