This is sad and frustrating. The article is trying to convince people to upgrade to a 7-year-old version of Python! And everyone is still skeptical about it, thinking it's too new, too risky, unproven, and libraries aren't ready yet.
Python 3 adoption takes longer than entire NodeJS lifetime. In the same timeframe PHP introduced and EOLed 5.3 (edit: and there were 4 years between release of 5.0 and EOL of 4.x, which involved backwards-incompatible refactoring of OO semantics).
I've said it before, I'll say it again. When all of the major Linux platforms provide the same pre-built Python 3 packages for the packages I use, I'll make the migration. Until then, it's just easier to stay on Python 2.
Yes, I could build the packages/wheels myself. Yes, I could install a compiler on the target machine and let the binaries build from scratch. I won't, however, since it's a lot of time for remarkably little benefit. Python 2 is still well supported, and is a great language to program in.
Yes, Python 3 has cleaned up some of the rough edges of Python 2; but the improvements are still not significant enough to offset the cost of porting libraries and building packages.
My problem with this post is not its factual accuracy. It's factually accurate, downright impressive.
My problem is with its premise. That premise is that Python 2.7 people need to be somehow educated. To be shown some kind of light. It's the same premise that the project leaders have been going on about for 7 years. "Can't you see how much better this is?". Worse: "are you 2.7 people stupid, or what?".
It hasn't worked.
Why hasn't it worked? Not because 2.x people are slow or uninformed. They're very well informed. They assess the merits and downsides. They've had 7 years!
The reason is a combination of inertia, but also, many people actually think that in many ways, 3.x is a regression. If you don't need Unicode, Unicode is a huge pain in the xxxx. I was just having to mess with "b"s everywhere today on strings over msgpack to a non-pythonic endpoint. Lazy ranges (can also be) a huge pain in the bt. So I must move to 3.5. For what? Type annotations? Asyncio? I've been using (the highly impressive) Tornado for 3 years on 2.7.
Now google brings out the brand new TensorFlow. On 2.7. "But porting to 3 is their #1 priority" I'm told. Okay cool. You wait. I won't.
So the advances of 3 meet the regressions of 3. Even if you believe the net is positive in 3's favour, that net is not nearly enough to persuade people with actual lives outside of computer science, to port years of code, and more importantly, to port their brains to work with the new dispensation. Python is a language for people who want to get things done. 2.7 gets things done. Zero problems. For many people, that's the killer feature.
Every programming language, programming language update, and programming tool since the dawn of time claims to make it easier to produce high-quality software.
Seriously though, the point is well taken. The right tool for the right job will always apply, and I like to think most developers and programmers acknowledge that there are very few tools that should be used in every opportunity and by every person.
And oftentimes it's true. Not sure what point you're trying to make here. The linked article pretty convincingly makes the case for the listed improvements in Python 2 -> 3.
Just because "Use X, it's better" is a frequently made argument doesn't mean it's wrong, especially when X actually is better!
That's because people don't generally make shittier things. It happens, rarely, on accident. But by and large (for computer languages) newer == better.
Python 3 is so far ahead now as a language that it surprises me anyone would even consider it for a new project. Among other things, Python 3.4 and 3.5 have added support for coroutines that provide a whole new level of utility to the language. Meanwhile, Python 2.7 is a study in limitations to anyone who has followed up on Python 3.x developments.
I still don't understand what happened here historically, was there ever an upgrade path or way to make this a smooth transition? I can't think (surely there is) of another language that had such a hard-breaking version change that still persists 10 years later as a fracture across the community.
VB6 versus VB.NET is a worse historic pothole of a version change for arguably the same language.
Ultimately the Python 2 -> 3 transition has been as smooth as developers make it. There are certainly a lot of transition efforts put in place, such as the ability to import from __future__ some of the 3 behaviors and abilities and some automated migration tools. At this point, too, most of the major libraries today support 3 and there's few reasons not to build for 3 and maybe do a few tweaks to also support 2, if you truly have to. (A lot of good 3 code runs on 2 unmodified and just needing the Python equivalent of polyfill libraries and __future__ imports.)
Some of the fracture has been binary ABI compatibility and mini-versions of this struggle can certainly be seen in just about any language with an ecosystem of cross-platform native libraries to support (the brief Node/io.js being an interesting fracture more in that it was resolved so amicably so relatively quickly).
But ultimately it's tough to resolve the psychological and political hurdles: for whatever reason there seem to be "die hard" Python 2 fanatics that hate the direction Python 3 has moved and don't seem interested at all in compromise or transition. It certainly doesn't seem to be as strong as the hate divide between VB6 and VB.NET (which will likely forever be a weird blood feud until VBA and VB6 programmers die of old age), but still haters are gonna hate.
It hasn't been 10 years. There were known IO performance regressions at the time 3.0 was released, nobody involved in releasing it would have said to use it in production right away. 3.1 was released ~6 years ago:
(Even if the above is deemed BS, the release of 3.0 was 7 years ago)
Many of the 3.0 features can be switched on in 2.7 and there were some attempts to automate as much of the code change as possible (but people ended up preferring to write code that runs on both 2.7 and 3.x, but I suppose that then is not really evidence of a fracture).
The transition has been pretty smooth, but quite slow. Nearly all the major libraries are update - IMHO if a library doesn't support Python 3 these day's it's probably unmaintained and should be avoided. There's plenty of support for transitioning smoothly especially with a handful of changes in 3.2 and 3.3 to make this even easier.
I think there are however a small number of very vocal people who didn't like the change, and their posts tend to linger...
Perl was the workhorse of the early web, when I was a young programmer interested in the web it seemed like the most worthwhile language I could learn. Perl isn't dead but it's lost most of its appeal, and a large part of that is due to the failed development on Perl 6.
There is a library (and script) called 2to3 that automates code translation from Python 2 to 3. I wouldn't rely on it for my own projects, but I have seen a number of authors use it successfully (e.g. write their app in Python 2 and tell users it is compatible with automatic translation).
If you're on 2.7.x, you can certainly import in quite of the newer features. There are also some resources for writing 2/3 compatible code, such as the six library and http://python-future.org/. It is no problem for fairly trivial applications, but I don't envy anyone who has to ensure 2/3 compat for a large project.
On a tangential note, no pun intended, I am a little confused. Why would you ever want compare in the manner of "TrickyAngle(6) < TrickyAngle(5)"? I can understand something like "trickyAngle_A.degrees < trickAngle_b.degrees" but when comparing instances of a class like that, when would one ever be...greater than the other?
Given that even a relatively inexperienced developer can easily port 2,500+ lines of Python 2 to Python 3 per day, there's really very little reason for anyone to still be on Python 2 regardless of the benefits or lack thereof of Python 3. This is especially true if you're not trying to take advantage of all the performance benefits of Python 3 right away, and are content just to wrap iterators in list() or whatever just to get the functionality working the same without much effort.
I picked up Python about 1 year ago as my hobby language, and following the common advice, I started with 3. But I quickly encounter two problems:
1) some libraries I actually wanted to use were still 2
2) When I tried to google a solution for something, more than once I stumbled across a code which just didn't work. Then it occurred to me, that this is because the example is Python 2, while I am on 3.
To sum it up, I later switched to 2, and everything was fine since then. I also asked my friend, who is a professional python programmer, and to this day his company still uses 2 and don't plan to switch.
This seems like your mental model assumes relatively small codebases. On a codebase with 1m LOC, your estimation of 2500 lines/day still takes ~400 person-days. That's a big investment to put into something that doesn't present clear benefits. Moreover, converting a huge codebase piecemeal is something of a challenge; I don't know if it's even possible to have python 2 importing python 3 (or vice versa) but assuming your large codebase is relatively interdependent, reorganizing the codebase such that you can split it into modules which can be migrated independently could also be a big undertaking. I would also anticipate that there would be a long tail of fixing bugs caused by incorrect migration (are we code reviewing those 2500 lines/day?) as well as lower productivity as developers get used to the new language.
This is why you frequently hear that large, established codebases that control their environment aren't updating to Python 3. It's pretty easy to move a few thousand lines over but complexity scales non-linearly with the size of the codebase.
Funnily, though, I just thought 'yeah there's that library I use, they never ported that', for one of my codebases. Just looked it up and they now have ported it. So I guess it's time for me to do the same. I wonder what proportion of (actually used) libs are Py 2 only still.
It's easy to port to python 3 but I think the holdup with some libraries is that they want to support both 2 and 3 with the same library so that devs who cannot upgrade the python on their system don't get left behind. Supporting both at the same time is possible but takes longer in most cases.
Majority of people dont care about new shiny, they care about things that broke or changed. Probably 90% of them started complaining because print statement is a function :).
Python 3 insistence on unicode hurts my brain. I had a 'pleasure' of writing Python 3 script manipulating data produced by Python 2 (custom pickle). Ended up reimplementing whole Python 2 pickle library by hand, because apparently no one imagined a use case involving reading raw bytes into a buffer.
The problem is really that Python 3 isn't new and shiny. It's an attempt to improve some downsides of Python 2 and some parts did actually get better but many parts didn't although they easily could have been improved, some parts even got worse.
Python 3 provides no real benefit to an experienced Python developer. So considering all the things you could possibly do, switching to Python 3 is not switchting to a new and shiny thing, it's just a bad decision.
If you really want to switch to something new and shiny, there are now many more interesting language options. Modern Javascript has copied so much from Python, you can feel very much at home there. If you care about concurrency, you have Go. If you care about concurrency and care about using a language that's well designed or just want performance, there is Rust.
Complaints about a language translate automatically to low-quality software the same way micro-optimizations automatically translate to fast software.
In the real world, software depends significantly more on the properties of a developer or a team. Building software is about people more than it's about tools.
Dealing with Unicode in Python 2.x is a _nightmare_. So if you need to go beyond ASCII, Python 3 is a huge improvement. On the downside, if you want to use tools like App Engine, you're still stuck with 2.7 for now, but hopefully that will change.
Python 2's handling of Unicode basically isn't. That's as much the fault of third party libraries as the core language, but it is a real and constant time suck.
I'm sure I hit Unicode problems in Python 3 a few years ago as well, but if current versions are better that would be a sufficient reason for switching.
This is excellent. The first one is totally unknown to me. I wish there is a comprehensive changes between 2.7 and 3.X with code, release notes is okay but falls under different version and hard to grasp at once.
It's really hard to keep up with language changes and implementation changes.
EDIT: I am so surprise at the number of downvotes in this HN thread. I bet there is some haters out there today :-)
The other items in the article are also mentioned there, but not as headline items. The great majority of behavioral changes from 2.7 to 3.x should be listed in that one document, there was a freeze on language changes for several of the 3.x releases.
The whole 2 vs. 3 debate would simply have not existed if the Python core devs would have simply refused to backport tweaks and fixes from 3 to 2 and would have forcefully deprecated 2.x immediately after releasing 3.0, even if it was inferior to 2.x at first release.
Guido should have used his power to force the move forward down people's throats, because that's the responsibility of a BDFL. The D is there for a reason, and its exactly in this cases that the power of the Dictator role should have been used.
Communities rarely move forward on their own if left to decide democratically: they need o be forced or tricked into moving forward by individuals with vision!
...heck, I'm even starting to like the nodejs folks for their "shove the future down people's throats" attitude :)
Most organizations that have been lingering at 2.7 for 5+yrs would have long since migrated to 2.9, and would thus be half way to 3.x in terms of backwards compatibility.
Now instead, everyone has to introduce the better part of a decade's worth of backwards compatibility changes at once, or be left in the dust. Hardly a fair choice.
I'm sorry, but given how much high quality software is written in Python 2, examples of high quality software written in Python 3 more easily would do a better job proving the central thesis of the article than pointing out design defects of Python 2 fixed in Python 3. Because at the end of the day, there are still plenty of design defects in Python 3 (or any other language) that a coder might trip over. I mean who is to say that new yield functionality of Python 3 wouldn't lead to hard to understand spaghetti code? Or the new way of handling Unicode isn't worse than the old way? Listing concrete projects that benefitted from being written in Python 3 rather than 2 would be much more convincing.
> I'm sorry, but given how much high quality software is written in Python 2
The reason for that isn't "Python 2 is intrinsically better than Python 3," though. It's the sheer inertia of a language whose last minor version (2.7) was released five years ago and the persistent meme that Python 3 is buggy and unusable, despite clear advantages as noted in the article and the added compatibility of popular Python 2 packages in recent years.
As with hardware, Python 2 will only die when the top packages completely drop support for it, and it wouldn't surprise me if that happens sooner than later. (Django, for example, will be dropping Python 2 support in 2017: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ )
It doesn't help that Mac books come with 2.7 installed. For someone starting out (Python is often used as a teaching language in CS101-esque classes), figuring out how to get one's machine to use 3 might seem really difficult/impossible.
Library compatibility is definitely an issue. You still have some very influential libraries that are not Python 3.x compatible. But an oft underestimated issue is the number of Py3 improvements that have been backported to Py2. For example absolute imports. That has made the case for moving to Py3 harder.
First, there's no easy way for library developers to maintain a codebase that supports both 2/3 development in parallel. Yes, it's easy to use a 2to3/3to2 tool but unlike transpilers in Javascript the output code may still require fine-tuning after the tranform.
This could be solved by adding preprocessor support to python (ie for conditional loading of code) but GvR is adamantly against this approach use to the way many devs write unmaintainable code in c via the preprocessor.
I actually published an OSS project called pypreprocessor that was supposed to solve this issue. It works to add preprocessor conditionals to code but won't work with both 2/3 code in the same file because there's no hook to inline code before lexer runs and throws syntax errors.
Second, package management in python still sucks. Do you use distutils, distutils2, setup.py, etc? There's no single standardized approach that everybody agrees on and each tool follows a unique approach or needs to be supported because of legacy code.
Unlike the Ruby, Javascript ecosystem where package management and publishing is relatively straightforward/easy, it's an absolute PITA to publish packages to PYPI.
Back in 2011, the answer was. Just wait 5 years for everybody to adapt their libraries to support Python 3. 5 years later, nothing has changed. The existing libraries don't want to piss off users by dropping Python2 support and maintaining two separate branches of the code in parallel sucks. So, since most everybody that uses python in production still relies on Python2, Python2 is still the default.
The library ecosystem makes the platform. The tooling sucks so library devs don't want to make the switch.
Until there is a major cultural shift python devs have 2 options. Use a better version of the language without the support of a mature library ecosystem, or use an outdated version of the language with a rich ecosystem.
We ported a major production site from python 2 to 3 a year ago. Exactly one bug has come up - something to do with unicode encoding on a relatively minor part of the site. Thanks to 2to3, the concerns for bugs coming up in porting are way overblown.
[+] [-] pornel|10 years ago|reply
Python 3 adoption takes longer than entire NodeJS lifetime. In the same timeframe PHP introduced and EOLed 5.3 (edit: and there were 4 years between release of 5.0 and EOL of 4.x, which involved backwards-incompatible refactoring of OO semantics).
[+] [-] falcolas|10 years ago|reply
Yes, I could build the packages/wheels myself. Yes, I could install a compiler on the target machine and let the binaries build from scratch. I won't, however, since it's a lot of time for remarkably little benefit. Python 2 is still well supported, and is a great language to program in.
Yes, Python 3 has cleaned up some of the rough edges of Python 2; but the improvements are still not significant enough to offset the cost of porting libraries and building packages.
[+] [-] stevecalifornia|10 years ago|reply
Both sides are extremely persuasive and thus I felt that no matter what choice I made it was the wrong one and would haunt me down the line.
So I just stuck with a different modern language that has wide acceptance and isn't battling with itself.
[+] [-] vegabook|10 years ago|reply
My problem is with its premise. That premise is that Python 2.7 people need to be somehow educated. To be shown some kind of light. It's the same premise that the project leaders have been going on about for 7 years. "Can't you see how much better this is?". Worse: "are you 2.7 people stupid, or what?".
It hasn't worked.
Why hasn't it worked? Not because 2.x people are slow or uninformed. They're very well informed. They assess the merits and downsides. They've had 7 years!
The reason is a combination of inertia, but also, many people actually think that in many ways, 3.x is a regression. If you don't need Unicode, Unicode is a huge pain in the xxxx. I was just having to mess with "b"s everywhere today on strings over msgpack to a non-pythonic endpoint. Lazy ranges (can also be) a huge pain in the bt. So I must move to 3.5. For what? Type annotations? Asyncio? I've been using (the highly impressive) Tornado for 3 years on 2.7.
Now google brings out the brand new TensorFlow. On 2.7. "But porting to 3 is their #1 priority" I'm told. Okay cool. You wait. I won't.
So the advances of 3 meet the regressions of 3. Even if you believe the net is positive in 3's favour, that net is not nearly enough to persuade people with actual lives outside of computer science, to port years of code, and more importantly, to port their brains to work with the new dispensation. Python is a language for people who want to get things done. 2.7 gets things done. Zero problems. For many people, that's the killer feature.
[+] [-] emodendroket|10 years ago|reply
[+] [-] Amorymeltzer|10 years ago|reply
Seriously though, the point is well taken. The right tool for the right job will always apply, and I like to think most developers and programmers acknowledge that there are very few tools that should be used in every opportunity and by every person.
[+] [-] CydeWeys|10 years ago|reply
Just because "Use X, it's better" is a frequently made argument doesn't mean it's wrong, especially when X actually is better!
[+] [-] rch|10 years ago|reply
[+] [-] njharman|10 years ago|reply
[+] [-] parent5446|10 years ago|reply
[+] [-] lyschoening|10 years ago|reply
[+] [-] tibbon|10 years ago|reply
[+] [-] WorldMaker|10 years ago|reply
Ultimately the Python 2 -> 3 transition has been as smooth as developers make it. There are certainly a lot of transition efforts put in place, such as the ability to import from __future__ some of the 3 behaviors and abilities and some automated migration tools. At this point, too, most of the major libraries today support 3 and there's few reasons not to build for 3 and maybe do a few tweaks to also support 2, if you truly have to. (A lot of good 3 code runs on 2 unmodified and just needing the Python equivalent of polyfill libraries and __future__ imports.)
Some of the fracture has been binary ABI compatibility and mini-versions of this struggle can certainly be seen in just about any language with an ecosystem of cross-platform native libraries to support (the brief Node/io.js being an interesting fracture more in that it was resolved so amicably so relatively quickly).
But ultimately it's tough to resolve the psychological and political hurdles: for whatever reason there seem to be "die hard" Python 2 fanatics that hate the direction Python 3 has moved and don't seem interested at all in compromise or transition. It certainly doesn't seem to be as strong as the hate divide between VB6 and VB.NET (which will likely forever be a weird blood feud until VBA and VB6 programmers die of old age), but still haters are gonna hate.
[+] [-] maxerickson|10 years ago|reply
https://www.python.org/download/releases/3.1/
(Even if the above is deemed BS, the release of 3.0 was 7 years ago)
Many of the 3.0 features can be switched on in 2.7 and there were some attempts to automate as much of the code change as possible (but people ended up preferring to write code that runs on both 2.7 and 3.x, but I suppose that then is not really evidence of a fracture).
[+] [-] mangecoeur|10 years ago|reply
I think there are however a small number of very vocal people who didn't like the change, and their posts tend to linger...
[+] [-] yellowstuff|10 years ago|reply
Perl was the workhorse of the early web, when I was a young programmer interested in the web it seemed like the most worthwhile language I could learn. Perl isn't dead but it's lost most of its appeal, and a large part of that is due to the failed development on Perl 6.
[+] [-] brbsix|10 years ago|reply
If you're on 2.7.x, you can certainly import in quite of the newer features. There are also some resources for writing 2/3 compatible code, such as the six library and http://python-future.org/. It is no problem for fairly trivial applications, but I don't envy anyone who has to ensure 2/3 compat for a large project.
[+] [-] snake_plissken|10 years ago|reply
[+] [-] Alex3917|10 years ago|reply
[+] [-] greyman|10 years ago|reply
1) some libraries I actually wanted to use were still 2
2) When I tried to google a solution for something, more than once I stumbled across a code which just didn't work. Then it occurred to me, that this is because the example is Python 2, while I am on 3.
To sum it up, I later switched to 2, and everything was fine since then. I also asked my friend, who is a professional python programmer, and to this day his company still uses 2 and don't plan to switch.
[+] [-] twright0|10 years ago|reply
This is why you frequently hear that large, established codebases that control their environment aren't updating to Python 3. It's pretty easy to move a few thousand lines over but complexity scales non-linearly with the size of the codebase.
[+] [-] sago|10 years ago|reply
Funnily, though, I just thought 'yeah there's that library I use, they never ported that', for one of my codebases. Just looked it up and they now have ported it. So I guess it's time for me to do the same. I wonder what proportion of (actually used) libs are Py 2 only still.
[+] [-] n0us|10 years ago|reply
[+] [-] tim333|10 years ago|reply
[+] [-] yeukhon|10 years ago|reply
[+] [-] rasz_pl|10 years ago|reply
Python 3 insistence on unicode hurts my brain. I had a 'pleasure' of writing Python 3 script manipulating data produced by Python 2 (custom pickle). Ended up reimplementing whole Python 2 pickle library by hand, because apparently no one imagined a use case involving reading raw bytes into a buffer.
[+] [-] DasIch|10 years ago|reply
Python 3 provides no real benefit to an experienced Python developer. So considering all the things you could possibly do, switching to Python 3 is not switchting to a new and shiny thing, it's just a bad decision.
If you really want to switch to something new and shiny, there are now many more interesting language options. Modern Javascript has copied so much from Python, you can feel very much at home there. If you care about concurrency, you have Go. If you care about concurrency and care about using a language that's well designed or just want performance, there is Rust.
[+] [-] gdulli|10 years ago|reply
In the real world, software depends significantly more on the properties of a developer or a team. Building software is about people more than it's about tools.
[+] [-] brianmcconnell|10 years ago|reply
[+] [-] yarrel|10 years ago|reply
I'm sure I hit Unicode problems in Python 3 a few years ago as well, but if current versions are better that would be a sufficient reason for switching.
[+] [-] Avernar|10 years ago|reply
[+] [-] yeukhon|10 years ago|reply
It's really hard to keep up with language changes and implementation changes.
EDIT: I am so surprise at the number of downvotes in this HN thread. I bet there is some haters out there today :-)
[+] [-] maxerickson|10 years ago|reply
https://docs.python.org/3.0/whatsnew/3.0.html
The other items in the article are also mentioned there, but not as headline items. The great majority of behavioral changes from 2.7 to 3.x should be listed in that one document, there was a freeze on language changes for several of the 3.x releases.
[+] [-] redsymbol|10 years ago|reply
http://migrateup.com/whats-really-new-in-python-3/
(Actually, maybe not, because it doesn't have code examples.)
[+] [-] nnq|10 years ago|reply
Guido should have used his power to force the move forward down people's throats, because that's the responsibility of a BDFL. The D is there for a reason, and its exactly in this cases that the power of the Dictator role should have been used.
Communities rarely move forward on their own if left to decide democratically: they need o be forced or tricked into moving forward by individuals with vision!
...heck, I'm even starting to like the nodejs folks for their "shove the future down people's throats" attitude :)
[+] [-] fuhrysteve|10 years ago|reply
Python 2.8: - boring easy to fix changes like division, print function, exception handling syntax, removal of iteritems() / etc
Python 2.9 - library reorganization (urllib2 & urllib, etc)
Python 3.0 - unicode stuff
Most organizations that have been lingering at 2.7 for 5+yrs would have long since migrated to 2.9, and would thus be half way to 3.x in terms of backwards compatibility.
Now instead, everyone has to introduce the better part of a decade's worth of backwards compatibility changes at once, or be left in the dust. Hardly a fair choice.
[+] [-] Grue3|10 years ago|reply
[+] [-] minimaxir|10 years ago|reply
The reason for that isn't "Python 2 is intrinsically better than Python 3," though. It's the sheer inertia of a language whose last minor version (2.7) was released five years ago and the persistent meme that Python 3 is buggy and unusable, despite clear advantages as noted in the article and the added compatibility of popular Python 2 packages in recent years.
As with hardware, Python 2 will only die when the top packages completely drop support for it, and it wouldn't surprise me if that happens sooner than later. (Django, for example, will be dropping Python 2 support in 2017: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ )
[+] [-] klunger|10 years ago|reply
[+] [-] sigzero|10 years ago|reply
[+] [-] avoutthere|10 years ago|reply
That is, unless said software needs to include a popular library that has not been ported.
[+] [-] eeZi|10 years ago|reply
[+] [-] dagw|10 years ago|reply
[+] [-] njharman|10 years ago|reply
[+] [-] pbhowmic|10 years ago|reply
[+] [-] EvanPlaice|10 years ago|reply
The ecosystem is rotting for 2 reasons.
First, there's no easy way for library developers to maintain a codebase that supports both 2/3 development in parallel. Yes, it's easy to use a 2to3/3to2 tool but unlike transpilers in Javascript the output code may still require fine-tuning after the tranform.
This could be solved by adding preprocessor support to python (ie for conditional loading of code) but GvR is adamantly against this approach use to the way many devs write unmaintainable code in c via the preprocessor.
I actually published an OSS project called pypreprocessor that was supposed to solve this issue. It works to add preprocessor conditionals to code but won't work with both 2/3 code in the same file because there's no hook to inline code before lexer runs and throws syntax errors.
Second, package management in python still sucks. Do you use distutils, distutils2, setup.py, etc? There's no single standardized approach that everybody agrees on and each tool follows a unique approach or needs to be supported because of legacy code.
Unlike the Ruby, Javascript ecosystem where package management and publishing is relatively straightforward/easy, it's an absolute PITA to publish packages to PYPI.
Back in 2011, the answer was. Just wait 5 years for everybody to adapt their libraries to support Python 3. 5 years later, nothing has changed. The existing libraries don't want to piss off users by dropping Python2 support and maintaining two separate branches of the code in parallel sucks. So, since most everybody that uses python in production still relies on Python2, Python2 is still the default.
The library ecosystem makes the platform. The tooling sucks so library devs don't want to make the switch.
Until there is a major cultural shift python devs have 2 options. Use a better version of the language without the support of a mature library ecosystem, or use an outdated version of the language with a rich ecosystem.
[+] [-] anewhnaccount|10 years ago|reply
[+] [-] m0th87|10 years ago|reply
[+] [-] agentultra|10 years ago|reply