I don't think people are used to backwards compatibility breaks in languages. Though in some ways, that means you have a different language.
In reality, Python 3 is to Python 2 what Ruby is to Python 2 - different. They aren't the same language, you could have named Python 3 Anaconda (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) and its function would be clearer.
But you also can't tell people writing free software "no, you have to stop doing what you want, and do what I want" unless you are willing to negotiate how much that will cost you. And maybe they wouldn't do it for any price. You could get other developers to extend it on your doll as well.
But the developers of Python collectively said "unicode is important enough to make a backwards incompatible leap". They are never painless. OpenGL is a great example, with how the version 3 line was rife with attempts to depreciate the fixed function legacy cruft, and even today few developers properly differentiate compatibility and core profiles. That is a major version break too.
But if you don't like it, you can make your own. The fact there isn't a major popular python2 extension project trying to backport functionality unofficially that has gained traction should say what the popular consensus on python 3 is.
If you need python2 libraries, use python2. There is really no shame in doing it. Even when the official project depreciates the maintenance of 2.7 someone will pick it up, because there will be for decades, at least, and probably for eternity, python 2 software running somewhere and the maintainers think keeping python 2 working is less effort than porting their stack to 3.
I don't think people are used to backwards compatibility breaks in languages.
Nor do they like it, because most if not all developers are using these languages for a practical purpose: to get things done. Having to relearn and "fix" things which otherwise wouldn't need to be has a cost, and this is on top of what they already have to do.
I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go. Outside of the software industry this is the norm; think of all the "interfaces" that we use in the physical world that have remained backwards-compatible and relatively stable over long periods of time. Software is different because it can change quickly and (by itself) easily, but just because it can doesn't mean it should, as if it is well-established, there is certainly a large number of dependencies on it too.
If the python developers wanted to spend the time to reimplemented bad behavior, they could have create a reverse "import from deprecated ...".
It would solve most of the problem, while encouraging a switch to the new'er version by forcing every user to type in "import from deprecated" in top of their script.
I just think they didn't want to do that, given the massive work and non-existent personal gain. However, any company that want to invest their money on it can since its open source.
If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3.
I guess, you don't mean what you said in the last paragraph? Was it just a joke?
Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like.
Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.
Ruby did it and we're not wringing our hands about how Ruby is dead. It's just that the whiners feel particularly empowered in Python, they believe they have a chance of getting Python 3 erased.
Within the few industries I've had a peek at (not hip startups or web companies) this doesn't appear to be that big of a problem. Companies that rely on Python 2 code in the background seem to be sticking with Python 2 without any noticeable penalty or incentive to change. And places that have their core business wrapped up in python seem to be gradually making the transition OK. It's not without cost but you do what you have to do...
This sort of thing isn't uncommon... I see old perl installs behind production software, ancient versions of RedHat, Oracle, etc. and I deal with mostly technology centric companies so that's likely just the tip of the iceberg. Old software doesn't really go away.
I learned Python in 2004 (circa Python 2.3) and since developed several years mainly in Python, but somewhere along this path I lost almost all my excitment and joy for this language. I used to dream in Python, now I find it cumbersome and to me Python 3 was an unnecessary pain and I also know some people are afraid to say it explicitly because you want to look as someone who remain on top of your game by being able to cope with new things, but knowing how to deal with Python 2/3 doesn't mean it was a good move. I'm now just happy to not have to develop in Python anymore.
yadda yadda. i'm happily developing in 3.4 and the improved exceptions alone make it worth it. the pain is pretty much limited to 3rd party libraries (getting better every day, though not nearly fast enough, true) and people not understanding bytes vs text (incidentally, mostly native english speakers.)
Agreed, Python 3 is in almost all aspects better and I really prefer 3 over 2. Most of the bigger 3rd libraries are already ported, at least all the ones I care about.
Numpy seems to be the biggest issue for most, but I guess it must be in some special area, I never found a need for it doing web development.
The unicode support removes so many of our problems, although I can understand the issues strings vs. bytes that a some people run into.
I've never really understood these claims that Python 3 only offers minor improvements over Python 2. Some of the improvements in Python 3 are quite significant: the example that comes to my mind first and foremost is that strings are now Unicode by default. These days you should really be using UTF-8 as your default encoding right across the board (the only exception being when you have to interact with legacy systems), and any language that doesn't make it so is quite frankly a deal-breaker as far as I'm concerned.
Agree. I've done a large project last year on python 2 and wish i could go back in time and start with python 3 right away.
To me unicode support really was the crappiest side of python, and it's good to know that it's supported now.
The problem for me with python is more general as just python 2 vs 3. It's that python seems stuck in the purely dynamic typing side of PL whereas the trend now (golang, haskell, dart , typescript) seems to be that types are useful for many things.
But sticking with python 2 wouldn't change anything to that matter.
I think the problem of Python 3 is, that it is too close to Python 2. Learning Python for the first time is really fun, compared to other languages. There is almost always a interesting technique that does exactly what you need and usually great tutorials. But switching from Python 2 to Python 3 is quite frustrating, it is just different enough that one can not rely on intuition, but it is similar enough to lure one into using intuition. With the added frustration that all the errors would just not be there in Python 2. So assuming that I will not get payed to become a Python 3 expert, I will just write Python 2 and pick up another language at some time in the future.
Mostly, what you need to become a "Python 3 expert" is learning the Python 2 __future__ module. Use it for a while, then the switch will be seamless, intuition-wise.
All my libraries run on Python 3 but I would recommend nobody to use them on that Python version if they can also use them on 2.x. They have better unicode support on 2.x and there are more 2.x users thus less bugs in 2.x specific code. Aside from that, the ecosystem for other libraries is bigger.
I completely agree. Since the release of Python 3, I've attempted to get familiar with Python and I always have this dilemma.
Which version do I learn first?
On a first, ignorant, glance learning Python 3 makes sense because it's the way of the future. Although, the more you learn, you slowly figure out that they're not that different; but, they're communities and supporting libraries are in two separate camps. It's like there's a cold war mentality of people who can't or won't port/migrate to 3 and the Python 3 crowd that looks upon the former with disgust and disdain. There's clearly a huge divide and it's uncomfortable and confusing for new folks to learn and get involved.
Now we're about 6 years since the first Python 3 release and I've never gotten involved with Python beyond a few days of tinkering. I've moved on, and based on my experience, people who are newcomers to programming are walking right by without a second thought. This coupled with the developers that are jumping ship, isn't good news for Python. They need a course change, and they need to make it quickly.
Even without python 3, it has become an increasingly complicated ecosystem. I run python 2.x on windows for scientific uses and find incompatibility to be a common problem. I need separate 32 bit and 64 bit versions which use different dlls that may or may not be in several possible locations and use incompatible libraries. Trying to run pypy or python 3 would be just to complicated.
Python is not a single ecosystem any more. We need separate distributions that can be self contained.
I've been told the Anaconda distribution (https://store.continuum.io/cshop/anaconda/) of Python can ease some of the pain there. The fact that I have to direct you to a "store" to download it does give me pause, however, even if the distribution is actually free.
This seems a bit overdramatic. Yes, the attempt to do a version number hijack by a influential set of developers is annoying but there is no reason that it can't be just ignored. Python 2.7 doesn't need new features. It is still wildly useful without them. It is perhaps even more useful without them...
You can't deprecate a computer language. Such a thing exists independently of implementations.
The problem is that there is a misconception that python libraries needs to be "maintained" and if they are not maintained they should not be used. However, many long-tail libraries really do not need to be "maintained": the code is well tested, works, and it has no security implications. Some of these libraries are just clever algorithms or re-engineering of some obscure protocol or format.
I guess this is one more reason that java is still the safest choice :( Sad.
Decent read - it further helped me appreciate the position from which Python 2 devs require certain non-trivial, non-ported libs are coming.
That said, as a mostly Python 3 developer, PEP 404, to which he links, provides much insight and justification for ending at 2.7. In brief, the changes all seem to me to be efforts to make Python more 'Pythonic' (i.e. TOOWTDI).
I'm curious what the lesson here is. A lot of the changes in Python 3, such as the byte format of strings, seem to be a good thing--just something that breaks compatibility.
Is the lesson never to bother fixing a major flaw in your software/language after it has been widely used/available?
There are two precedents to look at: Java and Perl.
Perl grew from merely useful to your-favorite-whiz-bang by being a decent language and growing a large collection of third-party modules. Then Larry Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and declared Perl6 to be The Future(tm). Years later, we have some remaining stuff that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot in an attempt to reach the Shangri-La of Perl 6. But, in many important respects, Perl is an ex-parrot and Parrot won't change that all that much.
Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot slower and gave you the worst of having a bad compiler and a stupid bytecode interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache) proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics through type erasure. Newer Java releases added some sorely-missing utility functions that you'd take for granted in other languages, such as converting between an array and an ArrayList, or splitting a string.
Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast compiler. It's not so bad, even though the language still bugs me sometimes.
What's in store for Python? Similarly to Perl, and differently to Java, Python2 has byte-strings, and just when people where coming to grips that there are some things for which str is a good fit and others where you want to use unicode, you got the "unicode as default" in Python3. A conservative approach would be to extend the language and libraries so that it becomes natural to use unicode objects in the places where you're dealing with text, and keep the functionality that bytestrings have around so that the old code is still working. Python3 did not choose the conservative approach - indeed the goal was to do all the compatibility-breaking things that were needed, upfront.
Despite that fact, there is hope that Python will not undergo the Parrot-to-ex-Parrot transition that Perl underwent. The Python core is already there, and many important libraries - including the numpy/Cython etc. toolsuite, and different web frameworks, are actively trying to find the remaining issues.
So, as a summary: A lot of the changes in Python 3, such as renaming the old strings into bytestrings and removing a lot of their functionality, are well-intentioned but have considerable problems. It definitely gets harder to fix major flaws in a language that is widely used, and blackmailing the users by declaring the "not as fun" old version of your language dead should not be done lightly if you don't want to become the next Perl.
I think the lesson is that if you're going to break backwards compatibility, you better offer something really enticing in exchange. Python 2 wasn't so broken that people where clamoring to get off it, and Python 3 wasn't so much of an improvement that people are clamoring to hop on it.
I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge.
Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.
I think, many more projects would have adopted Py3, if more extension modules would support it.
The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.
Maybe there are thousands of unported stuff but frankly, how much of that is useful/ready for production use (production=paid software with bug translating to losses) ? I'm perfectly fine with Pyside, SQLAlchemy, ReportLab and a bunch of few other things. I don't need the n-th lib with half baked, unicode broken, poor error handling, non portable, Disney-tested stuff. So, if only 10% of the libs have moved and those are the production quality stuff, then fine. What a useless article.
[+] [-] zanny|11 years ago|reply
In reality, Python 3 is to Python 2 what Ruby is to Python 2 - different. They aren't the same language, you could have named Python 3 Anaconda (just because Cobra is already taken, I know it is a prepackaged library bundle for Python already) and its function would be clearer.
But you also can't tell people writing free software "no, you have to stop doing what you want, and do what I want" unless you are willing to negotiate how much that will cost you. And maybe they wouldn't do it for any price. You could get other developers to extend it on your doll as well.
But the developers of Python collectively said "unicode is important enough to make a backwards incompatible leap". They are never painless. OpenGL is a great example, with how the version 3 line was rife with attempts to depreciate the fixed function legacy cruft, and even today few developers properly differentiate compatibility and core profiles. That is a major version break too.
But if you don't like it, you can make your own. The fact there isn't a major popular python2 extension project trying to backport functionality unofficially that has gained traction should say what the popular consensus on python 3 is.
If you need python2 libraries, use python2. There is really no shame in doing it. Even when the official project depreciates the maintenance of 2.7 someone will pick it up, because there will be for decades, at least, and probably for eternity, python 2 software running somewhere and the maintainers think keeping python 2 working is less effort than porting their stack to 3.
[+] [-] userbinator|11 years ago|reply
Nor do they like it, because most if not all developers are using these languages for a practical purpose: to get things done. Having to relearn and "fix" things which otherwise wouldn't need to be has a cost, and this is on top of what they already have to do.
I personally think backwards compatibility and gradual change - evolution, not revolution - is the way to go. Outside of the software industry this is the norm; think of all the "interfaces" that we use in the physical world that have remained backwards-compatible and relatively stable over long periods of time. Software is different because it can change quickly and (by itself) easily, but just because it can doesn't mean it should, as if it is well-established, there is certainly a large number of dependencies on it too.
[+] [-] belorn|11 years ago|reply
It would solve most of the problem, while encouraging a switch to the new'er version by forcing every user to type in "import from deprecated" in top of their script.
I just think they didn't want to do that, given the massive work and non-existent personal gain. However, any company that want to invest their money on it can since its open source.
[+] [-] PythonicAlpha|11 years ago|reply
If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3.
I guess, you don't mean what you said in the last paragraph? Was it just a joke?
Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like.
Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.
[+] [-] klibertp|11 years ago|reply
Actually, the name really is taken and by programming language: http://cobra-language.com/ - looked nice when I last looked.
I didn't know about Cobra Toolbox, however.
[+] [-] paddy_m|11 years ago|reply
[+] [-] pekk|11 years ago|reply
[+] [-] naner|11 years ago|reply
This sort of thing isn't uncommon... I see old perl installs behind production software, ancient versions of RedHat, Oracle, etc. and I deal with mostly technology centric companies so that's likely just the tip of the iceberg. Old software doesn't really go away.
[+] [-] doe88|11 years ago|reply
[+] [-] Scramblejams|11 years ago|reply
[+] [-] baq|11 years ago|reply
[+] [-] mrweasel|11 years ago|reply
Numpy seems to be the biggest issue for most, but I guess it must be in some special area, I never found a need for it doing web development.
The unicode support removes so many of our problems, although I can understand the issues strings vs. bytes that a some people run into.
[+] [-] jammycakes|11 years ago|reply
[+] [-] bsaul|11 years ago|reply
The problem for me with python is more general as just python 2 vs 3. It's that python seems stuck in the purely dynamic typing side of PL whereas the trend now (golang, haskell, dart , typescript) seems to be that types are useful for many things.
But sticking with python 2 wouldn't change anything to that matter.
[+] [-] postfuturist|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] yk|11 years ago|reply
[+] [-] u124556|11 years ago|reply
[+] [-] illumen|11 years ago|reply
[+] [-] akerl_|11 years ago|reply
http://python3wos.appspot.com/
[+] [-] the_mitsuhiko|11 years ago|reply
[+] [-] xpe|11 years ago|reply
I don't even know how to respond to such "logic".
[+] [-] pgtruesdell|11 years ago|reply
Which version do I learn first?
On a first, ignorant, glance learning Python 3 makes sense because it's the way of the future. Although, the more you learn, you slowly figure out that they're not that different; but, they're communities and supporting libraries are in two separate camps. It's like there's a cold war mentality of people who can't or won't port/migrate to 3 and the Python 3 crowd that looks upon the former with disgust and disdain. There's clearly a huge divide and it's uncomfortable and confusing for new folks to learn and get involved.
Now we're about 6 years since the first Python 3 release and I've never gotten involved with Python beyond a few days of tinkering. I've moved on, and based on my experience, people who are newcomers to programming are walking right by without a second thought. This coupled with the developers that are jumping ship, isn't good news for Python. They need a course change, and they need to make it quickly.
Just my $0.02.
[+] [-] ginko|11 years ago|reply
Python 3 is the way to go in the long run.
[+] [-] 7952|11 years ago|reply
Python is not a single ecosystem any more. We need separate distributions that can be self contained.
[+] [-] peatmoss|11 years ago|reply
[+] [-] ovis|11 years ago|reply
[+] [-] mwcampbell|11 years ago|reply
[+] [-] upofadown|11 years ago|reply
You can't deprecate a computer language. Such a thing exists independently of implementations.
[+] [-] tlogan|11 years ago|reply
The problem is that there is a misconception that python libraries needs to be "maintained" and if they are not maintained they should not be used. However, many long-tail libraries really do not need to be "maintained": the code is well tested, works, and it has no security implications. Some of these libraries are just clever algorithms or re-engineering of some obscure protocol or format.
I guess this is one more reason that java is still the safest choice :( Sad.
[+] [-] cot6mur3|11 years ago|reply
That said, as a mostly Python 3 developer, PEP 404, to which he links, provides much insight and justification for ending at 2.7. In brief, the changes all seem to me to be efforts to make Python more 'Pythonic' (i.e. TOOWTDI).
PEP 404 2 -> 3 reasoning: http://legacy.python.org/dev/peps/pep-0404/#and-now-for-some...
TOOWTDI: https://wiki.python.org/moin/TOOWTDI
[+] [-] Eyas|11 years ago|reply
Is the lesson never to bother fixing a major flaw in your software/language after it has been widely used/available?
[+] [-] sqrt17|11 years ago|reply
Perl grew from merely useful to your-favorite-whiz-bang by being a decent language and growing a large collection of third-party modules. Then Larry Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and declared Perl6 to be The Future(tm). Years later, we have some remaining stuff that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot in an attempt to reach the Shangri-La of Perl 6. But, in many important respects, Perl is an ex-parrot and Parrot won't change that all that much.
Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot slower and gave you the worst of having a bad compiler and a stupid bytecode interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache) proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics through type erasure. Newer Java releases added some sorely-missing utility functions that you'd take for granted in other languages, such as converting between an array and an ArrayList, or splitting a string.
Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast compiler. It's not so bad, even though the language still bugs me sometimes.
What's in store for Python? Similarly to Perl, and differently to Java, Python2 has byte-strings, and just when people where coming to grips that there are some things for which str is a good fit and others where you want to use unicode, you got the "unicode as default" in Python3. A conservative approach would be to extend the language and libraries so that it becomes natural to use unicode objects in the places where you're dealing with text, and keep the functionality that bytestrings have around so that the old code is still working. Python3 did not choose the conservative approach - indeed the goal was to do all the compatibility-breaking things that were needed, upfront.
Despite that fact, there is hope that Python will not undergo the Parrot-to-ex-Parrot transition that Perl underwent. The Python core is already there, and many important libraries - including the numpy/Cython etc. toolsuite, and different web frameworks, are actively trying to find the remaining issues.
So, as a summary: A lot of the changes in Python 3, such as renaming the old strings into bytestrings and removing a lot of their functionality, are well-intentioned but have considerable problems. It definitely gets harder to fix major flaws in a language that is widely used, and blackmailing the users by declaring the "not as fun" old version of your language dead should not be done lightly if you don't want to become the next Perl.
[+] [-] tormeh|11 years ago|reply
[+] [-] dagw|11 years ago|reply
[+] [-] marcosdumay|11 years ago|reply
[+] [-] PythonicAlpha|11 years ago|reply
Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.
I think, many more projects would have adopted Py3, if more extension modules would support it.
The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.
[+] [-] theseoafs|11 years ago|reply
[+] [-] sitkack|11 years ago|reply
[+] [-] wiz21|11 years ago|reply
[+] [-] jlarocco|11 years ago|reply
Most of the libraries I'd actually trust for more than a one off script are already ported or have plans for porting.
I wouldn't trust a lot of the unported libraries in a serious Python 2 project, anyway.
[+] [-] pacofvf|11 years ago|reply
[+] [-] KMag|11 years ago|reply
Sure they'll move on to python3, in the same way they moved on to C++, Scala, and VHDL.
Perhaps they will never abandon Python 2, like they haven't abandoned Cobol and Fortran. However, that doesn't mean they won't move on to Python 3.
[+] [-] fennecfoxen|11 years ago|reply
[+] [-] orkoden|11 years ago|reply
[+] [-] jevinskie|11 years ago|reply