20 years ago there was this great MP3 player, WinAmp 2. And then they released WinAmp 3, which broke compatibility with skins and plugins and which was slow. People didn't upgrade. Finally, they came to their senses and they released WinAmp 5, marketed as 2+3, which was faster and brought back compatibility with older stuff.
In the retail trading Forex world, there is this great trading app called MetaTrader 4. Many years ago they released MetaTrader 5, which broke backward compatibility and removed some popular features. People didn't upgrade. Today, they are finally bringing back the removed features and making MetaTrader 5 able to run MetaTrader 4 code.
Me, I wait for Python 5 (=2+3) which will be able to import Python 2 modules, so that you can gradually convert your code to the newer version.
I have tens of thousands of lines of Python 2 code in a big system. I can't just take 2 months off to move all of it to Python 3. Moving it in pieces is also not really possible, since there are many inter-dependencies.
Uglyfying my code with the "six" module it's also not a solution, since when I'll move, I won't care about Python 2 anymore.
So basically I'm just waiting until a consensus emerges.
It should be noted that the quantity of Python 2 code keeps on growing, I wrote most of my code while Python 3 existed. If Python 3 allowed an easy path forward, we wouldn't be in this situation.
All of the reasonable "2+3" features in Python have already landed, like u'' strings in Python 3.3. The really big issues, like the difference between strings and bytes objects, can't really be emulated away. This isn't like WinAmp or MetaTrader where you can just reimplement the old interface in the new application. Code that mixes strings and bytestrings freely is simply not going to interface well with Python 3 code.
There are few paths for upgrading. You haven't mentioned 2to3, but I will. I've migraded projects of the same size you mention (10s of kloc) with 2to3 and the process took days, not months. About three days with one developer, actually.
There are a number of projects which also have code bases which are compatible with both Python 2 and 3. You say that once you move, you won't care about Python 2 any more, but I that's not a good reason to reject six outright. In my experience, the code isn't really "uglified" but there are just a few minor cases here and there you need to think about.
Anyway. Small-ish projects like the one you are talking about are usually not as hard to migrate as you might think. There are some exceptions, of course.
Cython can probably compile your existing codebase such that it's compatible with both 2 and 3. Then you can write your new code in Python 3, while importing the old code as a C extension.
You can also do this piece-by-piece, if for some reason your code doesn't compile with Cython right away.
The compilation process also makes it much easier to identify bytes/unicode bugs, because you can choose to declare types.
> Uglyfying my code with the "six" module it's also not a solution, since when I'll move, I won't care about Python 2 anymore.
I've upgraded a lot of my code with just future imports and it is just a tiny step from there, unless you're doing a lot of character encoding. Leave those projects behind, but moving most other projects is easier than I expected.
> I have tens of thousands of lines of Python 2 code in a big system. I can't just take 2 months off to move all of it to Python 3. Moving it in pieces is also not really possible, since there are many inter-dependencies.
If you cant evolve a system incrementally because of excessive coupling, that's a problem, sure, but not a problem of either the platform you are on or the one you might be thinking about moving to, unless the former forced a tightly-coupled architecture on you.
I've used this module for upgrading a python2-only lib : https://pypi.python.org/pypi/future . Basically it allow you to write Python 3 code that will run on Python 2 interpreter (bar from using advanced features like coroutine or matrix mult operator).
The biggest obstacle people seem to complain about (besides print, which is trivial IMO) is unicode. This is generally also the most painful part of making python 2 code work on python 3.
The issue with it is that from unicode perspective your python 2 code is inherently broken. There's no automated tool that can fix it, and there's no way python 5 will be able to run python 2 code correctly unless unicode support would be removed. You have to manually tell python which string is made of characters and which one was made out of bytes.
You can automatically remove six from your codebase after you're Python 3.x only. So six can be a possible solution (provided you have automated tests).
I'm so glad to see this. I started with Python 1.4, and after several years too long on 2.6+ I've just recently been able to convince an employer to start a new codebase on Python 3.5. Having used it in production now, I would not willingly go back. Python 2.7 is excellent, but Py3 feels like "Py2 done right". It's at least as nice in every way and much nicer in quite a few.
I'm in a shop with solid microservice underpinnings, so our new project could just as easily have been in Go or something else for all its clients would know or care. Given that all the libraries we wanted to use were already available for Py3, this was a no-brainer. There were plenty of reasons to upgrade and no compelling reasons to stay on Py2. Should you find yourself in such a situation, I highly recommend investigating whether you can make the same move.
The Windows 10 approach - apply pain to the users until they "upgrade". Python 3 hasn't made it on its own merits, and we have fanboys like this trying to figure out some way to force people to upgrade.
Library porting to Python 3 did not go well. Many Python 2.x libraries were replaced by different Python 3 libraries from different developers. Many of the new libraries also work on Python 2. This creates the illusion that libraries are compatible across versions, but in fact, it just means you can now write code that runs on both Python 2 and Python 3. Converting old code can still be tough. (My posting on this from last year, after I ported a medium-size production application.[1] Note the angry, but not useful, replies from Python fanboys there.)
Python 3, at this point, is OK. But it was more incompatible than it needed to be. This created a Perl 5/Perl 6 type situation, where nobody wants to upgrade. The Perl crowd has the sense to not try to kill Perl 5.
Coming up next, Python 4, with optional unchecked type declarations with bad syntax. Some of the type info goes in comments, because it won't fit the syntax.
What kills me is, they decided to make breaking changes, and they still kept the damn global interpreter lock! It's like saying "Sorry guys, it's 2016, and you have to port all your code, but no parallelism for you!"
Just to add some perspective from another language: Ruby had a similar, traumatic rift when transitioning from 1.8 to 1.9. I don't think it's a coincidence that -- like Python 2.x to 3.x -- Unicode-handling was one of the changes...so even though Ruby 1.8 to 1.9 had fewer compatibility breaks than Python 2.x to 3.x, it still pissed off a lot of people.
But what made the community jump, IMO, was the fact that the Rails maintainers announced that they would be upgrading to 1.9 [0]. And since there is a very small subset of Ruby users who don't use Rails, that was the end of discussion.
Is there any library in Python that enjoys as much dominance over the language as Rails does to Ruby? Not from what I can tell...And virtually all of the big mindshare libraries in Python have made the transition (e.g. NumPy, Django)...So I agree with OP that making libraries commit to 3.x-or-else is the way to encourage adoption of 3.x...but I just don't see it working as well as it did for Rails/Ruby. That's not necessarily a bad thing, per se, in the sense that it shows the diversity of Python and its use-cases, versus Ruby and its majority use-case of Rails. But forcing the adoption of a version upgrade is one situation in which a mono-culture has the advantage (also, see iOS vs Android).
> For SymPy, the fact that 1/2 gives 0 in Python 2 has historically been a major source of frustration for new users.
I love Python, and I think Py3k is great. But I guess I have written too much C/C++ or something because integer division yielding integers (implicitly "with truncation") is what I would expect and not a float. And I'm a big fan of the "Principle of Least Surprise" but in this case I'm surprised to see int/int give float.
But, hey, like I said -- Py3k is a net improvement. And I'm sympathetic to new programmers and I love that Python's so popular for those new to coding.
Part of the problem is that the big hosting services don't even support Python 3 yet. Google App Engine and AWS Lambda don't support it, Heroku does but only for the past year, etc.
I'm building a brand new company and I'm being forced to use Python 2.7 because I'm using Lambda. This was my choice, but the point is I can't use 3 even if I want to.
That would make me pretty nervous. A couple of years from now, it will be taken for granted that all new Python projects are written in Python 3, and AWS Lambda will either be obsoleted by a Python 3-based competitor or--about the time you get your code built out--they will announce with great fanfare that Python 3 is their future and put projects like yours on the B Team's legacy infrastructure.
After "forcing" you to build your company on Python 2, they'll build theirs on Python 3 and too bad for you.
Agreed. When you start to work with python 3 it's a real drag to discover that your command line tools require a special virtualenv. It's not even a new problem, eg https://github.com/GoogleCloudPlatform/gsutil/issues/29
> Python 2.7 support ends in 2020. That means all updates, including security updates. For all intents and purposes, Python 2.7 becomes an insecure language to use at that point in time.
There are alternative python implementations like pypy, and they haven't expressed an intent to drop python 2.7 support. Only CPython 2.7 will then become an insecure interpreter.
I still don't get why they are noy just backporting the simple things people are missing. Like breaking: print "hello". I don't think being academically correct is worth the current schism.
That's far and away the easiest transition: start using parens in your Python 2.7 code today and you won't have to alter them when migration day comes.
You can fix this with one bash command, or an IDE, or whatever. Sounds like the people who can't upgrade are just , well, you fill in the word yourself.
Call me strange but I actually like that change. Not because I enjoy typing more, but because invalid syntax errors on print is an unambiguous warning that whatever code I just downloaded and ran is incompatible with 2.x
Without that, there may be other much more subtle bugs I'd have missed and spent time troubleshooting.
Python 3 ships with a utility that fixes that stuff with no work on your part just run 2to3 on all you're Python 2 source and like 99% of the differences are taken care of.
Nah, I'm good. Python 2.7 is not going to change. I have zero desire to port my code and gain zero benefit. I can actually write Python 2.7 with confidence that invoking "python2" won't break on the next rev of the OS.
Most likely, if CPython & crowd give up on 2.7, PyPy will carry the flag of "Stable Python" forward and that'll be that.
But if Python dies, I won't really be sad. Better languages are out there. :)
> But if Python dies, I won't really be sad. Better languages are out there. :)
Like what? I'm curious, because I've tried a lot of the newer languages out there, and I haven't found a general purpose one that I like nearly as much as Python. Elixir is really cool, but it has a pretty narrow focus, which makes it difficult for me to make the investment in learning it.
Why does this guy care if others don't drop Python2 support? Instead, live and let live.
Everyone is going to use what they want. People have been whining about this for almost a decade now, give it up. This community isn't going to be on one version again, and that is NOT the community's fault. It's the core dev team and Guido's for poor decision making, technical churn and refusal to go back and fix their mistakes. There's no technical reason why CPython can't run Python2 and 3 code, JVMs and the CLR have proven this sort of thing is possible.
If there's not strong enough support of Python3, let it die. Technical churn is not supposed to survive, not live on propaganda and coercion. I don't see the problem. If he bought into 3 before it succeeded, he created his own problem. I plan on porting what I have over when 3 actually gets over the hump but not before. That's what's in my best interests, which is what everyone should do (and it's exactly what the core dev team and GVR did).
Besides, if you're not into numerical Python and mainly use it for web, PyPy makes more sense to migrate to than Python3.
> I plan on porting what I have over when 3 actually gets over the hump but not before.
The popularity of major open source projects in Python have been ported or are in progress of porting over to Python 3 (mostly 3.3+).
I remember my boss telling me a few days ago in his previous job the codebase was still running Java 1.3 or 1.4. There was no incentive to upgrade because people were afraid of breaking changes, even from to the next major release. So when are they going to port over to 1.4? to 1.7 and then finally 1.8? God knows and trust me that'd be the day IBM AS400 support finally RIP. You can choose to live with that, but the pain of actually maintaining a codebase running on obsolete platform is pain. But ask Ansible maintainers, writing code that has to work with Python 2.3 was brittle. Ask anyone who has done RedHat administration they know too well how brittle working with a system totally 10 years ago (even though RH does support these old version for years). Pain in the fucking ass.
> If there's not strong enough support of Python3, let it die.
Where did you or the author get that? There is a strong motivation to go to Python 3. It just so happens people are still running on Linux that ships with Python 2 by default, or on MacOSX which is still on Python 2 by default.
If you maintain Django and you don't want to drop Python 2 support, you make the call. You don't have to join. He doesn't force people to join his collation. You are making a big deal out of his post/tweet.
I agree. And if you're into numerical Python, sticking with Python 2.7 is standard. Why would you migrate to Python3 when there is no performance benefit in numerical computing? If you're going to migrate may as well migrate to what will improve performance on the non-numpy bits (pypy) than a migration just for the sake of migrating (py3).
As a developer, it is difficult for me to move to Python 3 (and I want to). I'm working on a Django project and relying heavily on various Django plugins. There are a whole lot of plugins that are only supported for Python 2. Without much knowledge of Django landscape, I anticipated this and went with Python 2.7. Turned out to be a prudent decision that saved me tons of time.
I think it's instructional to consider what happened to Microsoft with Windows 8 here. They offered a product that users were utterly ambivalent about, and took a hardline "no debate, that's just how we're doing it" stance. And it totally flopped. So they offered some concessions in Windows 8.1, but by that point the narrative on Windows 8 had already formed and the brand was tarnished. So what was the fix? Windows 10. Arguably 10 isn't actually that different from 8 (I mean yeah, it's better, but if you installed a start menu in 8 it's really not that different). I think Windows 10 worked because by being a new windows, it got to form a new narrative separate from windows 8.
The way I see it, Python 3.4+ is a lot like Windows 8.1. It's actually really not bad, but the narrative around its predecessors will never let it truly succeed. The realistic way for python to move forward is to offer a brand new version (5 or 4, doesn't really matter), give some concessions to the python 2 people that will make them feel heard and feel reinvested (bring back the print statement, give us some long wanted things like not-stupid lambdas), and guarantee python 3 compatibility so they're not forking the damn project again.
I think at this point so many people have said bad things about Python 3 that the brand is toxic. A new version number might not really mean much technically, but symbolically as a sign to the python community that the devs have finally stopped being stubborn and arrogant and acknowledged they fucked up, it would be huge.
The people who really decide what you do don't care about syntax. They'll ask you if it is faster. And Python 3 is even slower than Python 2.
You don't have this problem with PHP. "Hey, Boss! We need to rewrite our code for PHP 7." – "Will it be faster? How much?" – "It will be faster. By factor X." – "Go on, make it so."
What about the open source developers that have been tired of the messy experience of python3.2 packaging?
That are doing this as a hobby. And don't have extensive time.
Why guilt us?
We are neither companies nor fundation's bitch.
Packaging in python is a mess, and every one wants to contribute to the shiny new features, and very few have to deal with the toilet cleaning that packaging (pypi, deb, rpm..), maintaining, dependency management, bug report platform consistency involves.
I am a bored as a maintainer to be expected to deal without a thanks for all the shit coming from the social pressure of "you should do this or blah" to comply with esoteric unproven needs that only results in more work and just more mess and layers of bureaucratic ideas disguised as "best practices".
I am no one's bitch. I am an open source coder. I code what I want, when I want, at the speed I want, and I am no slave that will do what he is being ordered.
Python 2 isn't going anywhere so long as the multi-million line 2.X codebases at big tech companies exist. Every big Python codebase I'm aware of is 2.x.
It's the same language. This is not the break between Perl 5 and 6 which was different languages only keeping the brand.
I find it very easy to write code which is simultaneously Python 2 and 3. A few ``from __future__ import`` statements and you'll be fine. The only reason some people are complaining is that they were ignoring bugs in their code regarding text data. It's not a Python problem, it's a problem with computers -- bytes are not text, but many systems ignore the difference.
Many large enterprises are starting new projects in Python 3 exclusively. It's fine if you want to use some Python 3-only syntax.
Honestly that was a big part of it for me, too and when node.js and io.js originally split I was worried for something far worse for the JavaScriot community. Fortunately node got its shit together (for the most part) but every time I try to use Python 3 for a project someone else tells me I can't because X, Y and Z so I have yet to use any Python 3. Kinda makes me sad in a way because it has lots of things I want to take advantage of.
But I do feel like tides are shifting and Python 3 is slowly "winning". It's just taking, what, almost a decade longer than most would have hoped?
Same here with me. But seeing how nothing is being done in perl anymore, I am forcing myself to at least start using python3. I don't see any point in learning ruby, and all the other new languages out there are sorta still niche. There is plenty going on though with python and django (at least jobwise)
But yes, the "now there are two ways to do it" brought on by 2 and 3 really sux.
I should also say I always hated the "small" syntax changes even between the point releases. This was also something that kept me away (ruby has this problem too). Perl never had this problem, stuff written in 2001 can still run on perl of 2016. But I see now that this is a double edge sword. I have worked for several companies that run modern perl versions but refuse to touch their code base that was written like it was 1998 because it just "still works". That was another reason I started looking into python. I very much welcome complete breakage every few years at this point. It will at least force people into staying modern with the stack they use instead of becoming a 15 year old fossil with a disgusting resume. (I mean, what would you do if someone sent a resume to your dev shop that said they have only done CGI perl for the last 15 years and have no idea what javascript is or why they should learn it?)
Start with Python 3, the differences isn't something that you can't pick up in an hour, and since you won't have existing python 2 code base you probably will never need to do that.
The biggest issue people are having is to convert their python 2 code to work on python 3. There's virtually no downside to use python 3. All maintained libraries work with python 3.
[+] [-] 21|10 years ago|reply
20 years ago there was this great MP3 player, WinAmp 2. And then they released WinAmp 3, which broke compatibility with skins and plugins and which was slow. People didn't upgrade. Finally, they came to their senses and they released WinAmp 5, marketed as 2+3, which was faster and brought back compatibility with older stuff.
In the retail trading Forex world, there is this great trading app called MetaTrader 4. Many years ago they released MetaTrader 5, which broke backward compatibility and removed some popular features. People didn't upgrade. Today, they are finally bringing back the removed features and making MetaTrader 5 able to run MetaTrader 4 code.
Me, I wait for Python 5 (=2+3) which will be able to import Python 2 modules, so that you can gradually convert your code to the newer version.
I have tens of thousands of lines of Python 2 code in a big system. I can't just take 2 months off to move all of it to Python 3. Moving it in pieces is also not really possible, since there are many inter-dependencies.
Uglyfying my code with the "six" module it's also not a solution, since when I'll move, I won't care about Python 2 anymore.
So basically I'm just waiting until a consensus emerges.
It should be noted that the quantity of Python 2 code keeps on growing, I wrote most of my code while Python 3 existed. If Python 3 allowed an easy path forward, we wouldn't be in this situation.
[+] [-] klodolph|10 years ago|reply
There are few paths for upgrading. You haven't mentioned 2to3, but I will. I've migraded projects of the same size you mention (10s of kloc) with 2to3 and the process took days, not months. About three days with one developer, actually.
There are a number of projects which also have code bases which are compatible with both Python 2 and 3. You say that once you move, you won't care about Python 2 any more, but I that's not a good reason to reject six outright. In my experience, the code isn't really "uglified" but there are just a few minor cases here and there you need to think about.
Anyway. Small-ish projects like the one you are talking about are usually not as hard to migrate as you might think. There are some exceptions, of course.
[+] [-] ash|10 years ago|reply
Thank you for saying this! For those interested in this direction, there was a discussion about it on HN a couple of months ago:
https://news.ycombinator.com/item?id=10823406
Proof-of-concept examples embedding Python interpreters within themselves:
https://gist.github.com/dutc/eba9b2f7980f400f6287
https://gist.github.com/dutc/2866d969d5e9209d501a
[+] [-] syllogism|10 years ago|reply
You can also do this piece-by-piece, if for some reason your code doesn't compile with Cython right away.
The compilation process also makes it much easier to identify bytes/unicode bugs, because you can choose to declare types.
[+] [-] njharman|10 years ago|reply
Welcome to the modern COBOL then. Have fun maintaining that and running only old libs cause everyone else in the world has passed you by.
> I'm just waiting until a consensus emerges.
Wake up, it's done emerged. Almost no libs aren't avail on 3 now.
[+] [-] ericfrederich|10 years ago|reply
According to this article Python2 support is shrinking.
https://blogs.msdn.microsoft.com/pythonengineering/2016/03/0...
[+] [-] mixmastamyk|10 years ago|reply
I've upgraded a lot of my code with just future imports and it is just a tiny step from there, unless you're doing a lot of character encoding. Leave those projects behind, but moving most other projects is easier than I expected.
[+] [-] dragonwriter|10 years ago|reply
If you cant evolve a system incrementally because of excessive coupling, that's a problem, sure, but not a problem of either the platform you are on or the one you might be thinking about moving to, unless the former forced a tightly-coupled architecture on you.
[+] [-] Dolores12|10 years ago|reply
> Moving it in pieces is also not really possible, since there are many inter-dependencies.
I guess something is wrong with your architecture in first place, so you can't separate domains or layers easily.
[+] [-] luch|10 years ago|reply
Once you decide not to support Python2 anymore, just drop the imports. They also have a Py2/3 compat cheet sheet : http://python-future.org/compatible_idioms.pdf
[+] [-] takeda|10 years ago|reply
The issue with it is that from unicode perspective your python 2 code is inherently broken. There's no automated tool that can fix it, and there's no way python 5 will be able to run python 2 code correctly unless unicode support would be removed. You have to manually tell python which string is made of characters and which one was made out of bytes.
[+] [-] svisser|10 years ago|reply
[+] [-] kstrauser|10 years ago|reply
I'm in a shop with solid microservice underpinnings, so our new project could just as easily have been in Go or something else for all its clients would know or care. Given that all the libraries we wanted to use were already available for Py3, this was a no-brainer. There were plenty of reasons to upgrade and no compelling reasons to stay on Py2. Should you find yourself in such a situation, I highly recommend investigating whether you can make the same move.
[+] [-] Animats|10 years ago|reply
Library porting to Python 3 did not go well. Many Python 2.x libraries were replaced by different Python 3 libraries from different developers. Many of the new libraries also work on Python 2. This creates the illusion that libraries are compatible across versions, but in fact, it just means you can now write code that runs on both Python 2 and Python 3. Converting old code can still be tough. (My posting on this from last year, after I ported a medium-size production application.[1] Note the angry, but not useful, replies from Python fanboys there.)
Python 3, at this point, is OK. But it was more incompatible than it needed to be. This created a Perl 5/Perl 6 type situation, where nobody wants to upgrade. The Perl crowd has the sense to not try to kill Perl 5.
Coming up next, Python 4, with optional unchecked type declarations with bad syntax. Some of the type info goes in comments, because it won't fit the syntax.
Stop von Rossum before he kills again.
[1] http://www.gossamer-threads.com/lists/python/python/1187134
[+] [-] cvwright|10 years ago|reply
Beatings will continue until morale improves...
[+] [-] danso|10 years ago|reply
But what made the community jump, IMO, was the fact that the Rails maintainers announced that they would be upgrading to 1.9 [0]. And since there is a very small subset of Ruby users who don't use Rails, that was the end of discussion.
Is there any library in Python that enjoys as much dominance over the language as Rails does to Ruby? Not from what I can tell...And virtually all of the big mindshare libraries in Python have made the transition (e.g. NumPy, Django)...So I agree with OP that making libraries commit to 3.x-or-else is the way to encourage adoption of 3.x...but I just don't see it working as well as it did for Rails/Ruby. That's not necessarily a bad thing, per se, in the sense that it shows the diversity of Python and its use-cases, versus Ruby and its majority use-case of Rails. But forcing the adoption of a version upgrade is one situation in which a mono-culture has the advantage (also, see iOS vs Android).
[0] http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-r...
[+] [-] wyldfire|10 years ago|reply
I love Python, and I think Py3k is great. But I guess I have written too much C/C++ or something because integer division yielding integers (implicitly "with truncation") is what I would expect and not a float. And I'm a big fan of the "Principle of Least Surprise" but in this case I'm surprised to see int/int give float.
But, hey, like I said -- Py3k is a net improvement. And I'm sympathetic to new programmers and I love that Python's so popular for those new to coding.
[+] [-] jedberg|10 years ago|reply
I'm building a brand new company and I'm being forced to use Python 2.7 because I'm using Lambda. This was my choice, but the point is I can't use 3 even if I want to.
[+] [-] SiVal|10 years ago|reply
After "forcing" you to build your company on Python 2, they'll build theirs on Python 3 and too bad for you.
[+] [-] rcpt|9 years ago|reply
[+] [-] edwinyzh|9 years ago|reply
[+] [-] rahiel|10 years ago|reply
There are alternative python implementations like pypy, and they haven't expressed an intent to drop python 2.7 support. Only CPython 2.7 will then become an insecure interpreter.
[+] [-] hartator|10 years ago|reply
[+] [-] kstrauser|10 years ago|reply
[+] [-] ta_389ty4|10 years ago|reply
[+] [-] Karunamon|10 years ago|reply
Without that, there may be other much more subtle bugs I'd have missed and spent time troubleshooting.
[+] [-] pmorici|10 years ago|reply
[+] [-] pnathan|10 years ago|reply
Most likely, if CPython & crowd give up on 2.7, PyPy will carry the flag of "Stable Python" forward and that'll be that.
But if Python dies, I won't really be sad. Better languages are out there. :)
[+] [-] RussianCow|10 years ago|reply
Like what? I'm curious, because I've tried a lot of the newer languages out there, and I haven't found a general purpose one that I like nearly as much as Python. Elixir is really cool, but it has a pretty narrow focus, which makes it difficult for me to make the investment in learning it.
[+] [-] BuckRogers|10 years ago|reply
Everyone is going to use what they want. People have been whining about this for almost a decade now, give it up. This community isn't going to be on one version again, and that is NOT the community's fault. It's the core dev team and Guido's for poor decision making, technical churn and refusal to go back and fix their mistakes. There's no technical reason why CPython can't run Python2 and 3 code, JVMs and the CLR have proven this sort of thing is possible.
If there's not strong enough support of Python3, let it die. Technical churn is not supposed to survive, not live on propaganda and coercion. I don't see the problem. If he bought into 3 before it succeeded, he created his own problem. I plan on porting what I have over when 3 actually gets over the hump but not before. That's what's in my best interests, which is what everyone should do (and it's exactly what the core dev team and GVR did).
Besides, if you're not into numerical Python and mainly use it for web, PyPy makes more sense to migrate to than Python3.
[+] [-] yeukhon|10 years ago|reply
The popularity of major open source projects in Python have been ported or are in progress of porting over to Python 3 (mostly 3.3+).
I remember my boss telling me a few days ago in his previous job the codebase was still running Java 1.3 or 1.4. There was no incentive to upgrade because people were afraid of breaking changes, even from to the next major release. So when are they going to port over to 1.4? to 1.7 and then finally 1.8? God knows and trust me that'd be the day IBM AS400 support finally RIP. You can choose to live with that, but the pain of actually maintaining a codebase running on obsolete platform is pain. But ask Ansible maintainers, writing code that has to work with Python 2.3 was brittle. Ask anyone who has done RedHat administration they know too well how brittle working with a system totally 10 years ago (even though RH does support these old version for years). Pain in the fucking ass.
> If there's not strong enough support of Python3, let it die.
Where did you or the author get that? There is a strong motivation to go to Python 3. It just so happens people are still running on Linux that ships with Python 2 by default, or on MacOSX which is still on Python 2 by default.
If you maintain Django and you don't want to drop Python 2 support, you make the call. You don't have to join. He doesn't force people to join his collation. You are making a big deal out of his post/tweet.
[+] [-] akubera|10 years ago|reply
Don't you think that mentality is part of the problem?
[+] [-] daveguy|10 years ago|reply
[+] [-] zellyn|10 years ago|reply
[+] [-] skizm|10 years ago|reply
[+] [-] jtchang|10 years ago|reply
[+] [-] xapata|10 years ago|reply
[+] [-] noisy_boy|10 years ago|reply
[+] [-] overgard|10 years ago|reply
The way I see it, Python 3.4+ is a lot like Windows 8.1. It's actually really not bad, but the narrative around its predecessors will never let it truly succeed. The realistic way for python to move forward is to offer a brand new version (5 or 4, doesn't really matter), give some concessions to the python 2 people that will make them feel heard and feel reinvested (bring back the print statement, give us some long wanted things like not-stupid lambdas), and guarantee python 3 compatibility so they're not forking the damn project again.
I think at this point so many people have said bad things about Python 3 that the brand is toxic. A new version number might not really mean much technically, but symbolically as a sign to the python community that the devs have finally stopped being stubborn and arrogant and acknowledged they fucked up, it would be huge.
[+] [-] noobiemcfoob|10 years ago|reply
I can't say I've come across an issue caused by an incompatibility between the two since the first couple months after switching...
[+] [-] stesch|10 years ago|reply
You don't have this problem with PHP. "Hey, Boss! We need to rewrite our code for PHP 7." – "Will it be faster? How much?" – "It will be faster. By factor X." – "Go on, make it so."
[+] [-] SFJulie|9 years ago|reply
That are doing this as a hobby. And don't have extensive time.
Why guilt us?
We are neither companies nor fundation's bitch.
Packaging in python is a mess, and every one wants to contribute to the shiny new features, and very few have to deal with the toilet cleaning that packaging (pypi, deb, rpm..), maintaining, dependency management, bug report platform consistency involves.
I am a bored as a maintainer to be expected to deal without a thanks for all the shit coming from the social pressure of "you should do this or blah" to comply with esoteric unproven needs that only results in more work and just more mess and layers of bureaucratic ideas disguised as "best practices".
I am no one's bitch. I am an open source coder. I code what I want, when I want, at the speed I want, and I am no slave that will do what he is being ordered.
[+] [-] incepted|10 years ago|reply
[+] [-] jamwt|10 years ago|reply
[+] [-] nelmaven|10 years ago|reply
[+] [-] xapata|10 years ago|reply
I find it very easy to write code which is simultaneously Python 2 and 3. A few ``from __future__ import`` statements and you'll be fine. The only reason some people are complaining is that they were ignoring bugs in their code regarding text data. It's not a Python problem, it's a problem with computers -- bytes are not text, but many systems ignore the difference.
Many large enterprises are starting new projects in Python 3 exclusively. It's fine if you want to use some Python 3-only syntax.
[+] [-] BinaryIdiot|10 years ago|reply
But I do feel like tides are shifting and Python 3 is slowly "winning". It's just taking, what, almost a decade longer than most would have hoped?
[+] [-] mixmastamyk|10 years ago|reply
[+] [-] esaym|10 years ago|reply
But yes, the "now there are two ways to do it" brought on by 2 and 3 really sux.
I should also say I always hated the "small" syntax changes even between the point releases. This was also something that kept me away (ruby has this problem too). Perl never had this problem, stuff written in 2001 can still run on perl of 2016. But I see now that this is a double edge sword. I have worked for several companies that run modern perl versions but refuse to touch their code base that was written like it was 1998 because it just "still works". That was another reason I started looking into python. I very much welcome complete breakage every few years at this point. It will at least force people into staying modern with the stack they use instead of becoming a 15 year old fossil with a disgusting resume. (I mean, what would you do if someone sent a resume to your dev shop that said they have only done CGI perl for the last 15 years and have no idea what javascript is or why they should learn it?)
[+] [-] takeda|9 years ago|reply
The biggest issue people are having is to convert their python 2 code to work on python 3. There's virtually no downside to use python 3. All maintained libraries work with python 3.