48 ms·

Moving Away from Python 2

227 points by ngoldbaum 10y ago

skizm 10y ago
It is pretty simple: when I spin up an EC2 instance on amazon, and I type "python" in the console, whatever version that is will be the version I use.
- lima 10y ago
  Nowadays, I no longer use the distribution Python at all. Debian Stable and pyenv it is. That way, I have a rock solid operating system and my application are completely decoupled. Using distribution packages for application deployments is insane. It makes sense for workstation or systems software where the application you develop is part of the operating system, but for a server application, it makes no sense at all.
  - snuxoll 10y ago
    I use distribution packages for all my deployments, period. I have no desire to maintain a separate system for installing an upgrading my own applications versus those provided in repositories already. Time to push out a new release? `tito release koji-el7`, SRPM built and sent to Koji to be built and packaged, every 15 minutes mash runs to update our internal yum repo from Koji - and next time Puppet runs the package is automatically upgraded to the latest version without me having to do anything. No virtualenv's, no tarballs, nothing special beyond an RPM. I won't deploy software any other way (and if something doesn't already have an RPM I will make one for it).
    - kstrauser 10y ago
      Note to self: snuxoll likes pushing boulders up hills by ignoring all the tooling people have invented to make this stuff easy.
      - snuxoll 10y ago
        > ignoring all the tooling people have invented to make this stuff easy. I don't, I just use the standard one that comes with the operating system instead of insisting on re-inventing the wheel because "packaging is hard". I could have just had tito push directly to a yum repository if I so desired, but it's much nicer to use Koji (which I'm already familiar with).
        kstrauser 10y ago
        > I don't, I just use the standard one that comes with the operating system ...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems: 1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.
        snuxoll 10y ago
        virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path. Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both. Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).
        10y ago
    - takeda 10y ago
      https://ius.io/ https://ius.io/ is your friend. Among many things you have all versions of python available that don't conflict with system packages or themselves. What's awesome is that you can install multiple versions and all of them just work.
  - matt_wulfeck 10y ago
    They aren't completely decoupled. Even with a virtenv you still need to install and maintain a lot of library and header packages on the host OS.
    - lima 10y ago
      Well, almost completely. The build dependencies don't change nearly as fast as the application, and are generally backwards compatible.
    - Filligree 10y ago
      For complete decoupling, better use NixOS.
      - lima 10y ago
        Or Docker containers :-)
    - takeda 10y ago
      That's problem which is solved with wheels.
  - mixmastamyk 10y ago
    No sense? What if you are happy with the current version and don't plan on changing it before changing the OS? What if you don't install more than one app on a system, or are using containers? Then you might not need the extra complexity.
    - klodolph 10y ago
      Even then. Suppose you want to change the OS for some reason. LTS eventually ends, maybe you want to change out some common library, or whatever. It's nice to have the option.
      - mixmastamyk 10y ago
        You could do it when you need it, ala YAGNI.
- sp332 10y ago
  Is it that much more work to type "python3" ?
  - dyeje 10y ago
    What's the incentive? How discoverable is that? As someone not familiar with Python, I certainly would never guess to type 'python3'.
    - deleted 10y ago
      [deleted]
    - sp332 10y ago
      Python 2 and python 3 are not the same language. There are big breaking changes between them. Most distros kept "python" pointing at python 2 to avoid breaking old scripts. If you want Python 3, you have to ask for it.
      - xapata 10y ago
        Yes, there is a breaking change. No, they are still essentially the same language.
        sp332 10y ago
        I mean it's a different binary with a different interpreter.
    - mixmastamyk 10y ago
      If you are not familiar with it, why are you running the interactive interpreter? If you are running someone else's script, they will have chosen python3 for you if it is a requirement.
    - zokier 10y ago
      Distros are dropping/have dropped python2 from default install. So incentive is that py3k is available out-of-the-box while you need to install py2 separately. As for discoverability, typing pyt<tab><tab> is probably what most people would do and that discovers python3 just fine.
- d0m 10y ago
  You still need to pick your linux distro.. and they aren't all running the same version. E.g. archlinux symlinks python to python3.
- johnny22 10y ago
  python will probably always run python2. if you wanna see if python3 is installed, then type python3.
wyldfire 10y ago
> 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.
- irremediable 10y ago
  I think part of the "surprise" comes from Python being so versatile. I mostly use it for prototyping numerical programming in a research setting, i.e. like MATLAB. So I'm occasionally surprised by the integer division stuff, because I want to just treat my numbers as numbers and be done with it. OTOH, when I'm doing systemsy stuff, it doesn't surprise me at all.
- ufo 10y ago
  The integer division is more surprising in a dynamic language because it might stay undetected until the day you happen to pass round numbers to your function.
  - wyldfire 10y ago
    I don't think you're correct. If you, the designer, made those operands, you should expect them to be int() or float() because of how you created them. int() and float() have lots of other differences beyond just how they're treated by division.
    - Thrymr 10y ago
      "you, the designer" may not have created the operands, just taken them as function arguments. Sure, you should have written tests for different types of input, but if you didn't, it may surprise you later.
    - 10y ago
rahiel 10y ago
> 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.
- nas 10y ago
  If you think Python 2.x support ends when the core team stops supporting it, you haven't been studying history. Programming platforms with large code bases (e.g. Cobol, Fortran) have extremely long lifetimes. What's more expensive: 1) porting millions (possibily billions) of lines of working Python 2.x code to Python 3 2) keeping the Python 2.7.x interpreter in deep maintenance mode? This idea that you can force people to move to Python 3 keeps coming up and is misguided, IMHO. There are two proper solutions to this issue: 1) make it easier to port from 2.x to 3.x. We are still making progress. Python 3.5 includes %-style formatting for byte strings. Allowing 'u' as a prefix for strings was another example. Practicality beats purity. 2) make 3.x a more compelling platform for new development. The amount of goodies in 3.0 was pretty underwhelming. I certainly wasn't very excited about moving to it. Async IO is a neat feature. Keep them coming.
  - bjt2n3904 10y ago
    This is the problem with Python 3. The arrogance of the people in support of wrestling it from us. > Frankly, if these "carrots" haven't convinced you yet, then I'll wager you're not really the sort of person who is persuaded by carrots. As someone that uses Python as a C replacement for one-off-scripts that work with binary objects and pure ASCII, Unicode is not a carrot. Unicode will never be a carrot. If anything, Unicode keeps me away. If I was developing web apps, GUI programs, or data processing libraries, sure. These would all be carrots. But I'm not. The simplicity of Python 2 is my carrot. > Python 3 does have carrots, and I want them. You have them. But you seem to be more interested in taking away my carrots, so you don't have to worry about them any more. That's arrogance.
BuckRogers 10y ago
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.
- daveguy 10y ago
  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).
  - yeukhon 10y ago
    Proof that there is no performance improvement? There are some changes in PY3 making CPython more performant in some areas, but in some other areas PY3 may perform worse. There was a PyCon talk about this a few years back.
    - daveguy 10y ago
      I haven't seen any proof there is a performance improvement. The only comprehensive benchmarks I have seen show on par or worse performance. If you are going to improve the performance of something I think it is on the "improved" system to demonstrate an improvement.
melling 10y ago
There's a yearly discussion about moving from Python 2 to 3. https://news.ycombinator.com/item?id=8730156 https://news.ycombinator.com/item?id=8730156 https://news.ycombinator.com/item?id=7005711 https://news.ycombinator.com/item?id=7005711 It's not a very productive use of time.
- rcarmo 10y ago
  I thought it was monthly. Seems to happen around the 20th each time, every time a Python piece gets posted...
Bromskloss 10y ago
I want Python 4 already!
noisy_boy 10y ago
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.
- rspeer 10y ago
  Interestingly, Django is one of the big projects that has already announced they're dropping Python 2 support before 2020. Django 1.11, to be released in April 2017, is scheduled to be the last version to support Python 2. [1] They've prudently made their last Py2 release a long-term support release, but if you want new Django features after December 2017, you're going to be using Python 3. Django works great on Python 3, BTW, and if you've got plugins that haven't updated, I would recommend being a bit suspicious of their code quality. [1] https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
  - 0xADEADBEE 10y ago
    If it helps anyone, 1.8 works with 2.7 and was an LTS release, which is supported until April 2018. You don't get the cool new features like Channels out of the box, but they're available via third parties.
- AdamN 10y ago
  I started a new project in Django recently and Python3 was obviously the choice. The nice thing is that if a library doesn't support Python3 then it's a good smell that it's bloated (or 'mature') and worth finding a replacement for. Sadly, many legacy Django packages are basically losing steam and shouldn't be used.
21 10y ago
I've seen this story happen twice before. 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.
- takeda 10y ago
  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.
- ash 10y ago
  > 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. 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 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/eba9b2f7980f400f6287 https://gist.github.com/dutc/2866d969d5e9209d501a https://gist.github.com/dutc/2866d969d5e9209d501a
nelmaven 10y ago
This sort of war between Python 2 and Python 3 is why I never looked seriously into Python. I don't know where should I start.
- esaym 10y ago
  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?)
- mixmastamyk 10y ago
  Python 3.5, installed by default on LTS distributions, and available everywhere else.
  - esaym 10y ago
    Python 3.6
    - mixmastamyk 10y ago
      No, still in alpha. If you're just tinkering, sure.
  - 10y ago
jtchang 10y ago
I am so annoyed at Python for not having a good upgrade path with backwards compatibility. Even with iOS you can use Swift code along with ObjC.
- xapata 10y ago
  I haven't had trouble upgrading. What issues are you encountering?
  - stesch 10y ago
    No web2py for Python 3.
    - _asummers 10y ago
      I took parallel algorithms with the guy that wrote that framework. Interesting to see it pop up on HN.
  - jhasse 10y ago
    SCons not supporting Python 3.
  - joobus 10y ago
    Twisted doens't support py3.
    - reubano 10y ago
      That's only half true [1] [1] https://github.com/twisted/twisted/blob/twisted-16.2.0/twisted/python/dist3.py https://github.com/twisted/twisted/blob/twisted-16.2.0/twist...
TorKlingberg 10y ago
Is there any reasonable measurement of Python 3 market share? I guess it's still <25%.
- BuckRogers 10y ago
  It's tough to know but I keep an eye on this stuff. You can count on a solid ~10% marketshare for Python3. Going too far beyond that without updated numbers would be overly generous. Roughly 12% of PyPi has been ported to Python3[0] and about 10% of pip downloads are Python3[1]. [0]https://youtu.be/G-uKNd5TSBw?t=1m14s https://youtu.be/G-uKNd5TSBw?t=1m14s [1]https://twitter.com/dstufft/status/687663858408919042 https://twitter.com/dstufft/status/687663858408919042
  - kstrauser 10y ago
    More importantly (to me) is that Py3 uploads have now exceeded Py2, according to https://twitter.com/chupapuma/status/730088983586181120 https://twitter.com/chupapuma/status/730088983586181120
    - BuckRogers 10y ago
      I saw that one too but Py3 hasn't actually intersected with Py2 yet. Uploads will level off. It doesn't have relevance on a marketshare question, it would be misleading. It does show some momentum. Most everything you would want already exists on Python2. A lot of those uploads are forks or new projects that already have solutions in 2. I have no problem with Python3 and glad to see people putting their money where their mouth is and 'get to porting'. Rather than blogs/complaining about the userbase/backroom deals and conspiracies to kill Python2.
- theseatoms 10y ago
  What do you mean by "market" in this context? Percentage of firms using either? Or do you just mean SLOC?
- karim 10y ago
  No there isn't. People used to be able to extrapolate it from the pypi downloads stats (like this: https://alexgaynor.net/2014/jan/03/pypi-download-statistics/ https://alexgaynor.net/2014/jan/03/pypi-download-statistics/), but sadly it's not possible anymore.
pnathan 10y ago
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. :)
- RussianCow 10y ago
  > 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.
  - jdimov9 10y ago
    Elixir _is_ the correct answer. Not sure what you mean by "narrow focus" - it is as general purpose as anything. Only thing holding me back from fully moving from Python to Elixir is that the ecosystem isn't mature enough yet.
    - zeemonkee3 10y ago
      I like Elixir, but the ecosystem has years of catching up to be anywhere close to Python. Not just libraries but experienced developers. There's also a danger it might end up like Ruby - basically the support system for a web framework.
      - true_religion 10y ago
        Elixir is nice, but I hardly think it compares to Python due to the fact that you are required to hand back control from a native call approximately every half second or so or else you will screw the internal scheduler on the ErlangVM.
    - 10y ago
incepted 10y ago
I have a feeling that by the time this happens, a lot of the Python developers will have moved to Go or some other language.
metalliqaz 10y ago
I'll transition when pypy transitions.
- reubano 10y ago
  http://doc.pypy.org/en/latest/release-pypy3-2.4.0.html http://doc.pypy.org/en/latest/release-pypy3-2.4.0.html
  - BuckRogers 10y ago
    It's well-known that PyPy3 is not production-ready. I've spoken with them about this many times over the years and it's not being worked on like PyPy5 is.
kstrauser 10y ago
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.
- albasha 10y ago
  Which framework are you using for the said microservice?
  - kstrauser 10y ago
    Flask + Flask-RESTful for this one.
hartator 10y ago
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.
- kstrauser 10y ago
  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.
  - iak8god 10y ago
    And use __future__ to force yourself not to forget: https://docs.python.org/2/library/__future__.html https://docs.python.org/2/library/__future__.html
- ta_389ty4 10y ago
  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.
- Karunamon 10y ago
  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.
- pmorici 10y ago
  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.
  - nomel 10y ago
    Why not have "print thing" to "print(thing)" just be an automatic conversion though?
danso 10y ago
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). [0] http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-ruby-1-9/ http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-r...
- Freaky 10y ago
  Ruby 1.9 rewarded your upgrade efforts by running twice as fast. There was a lot of enthusiasm to migrate. Python 3 still seems to reward you by running slightly slower. Where's the hook? Marginal improvements to language design are bit of a weak sell for a language that's already pretty nice.
  - wbond 10y ago
    All of the testing I've done with real-world code has shown an improvement of 10-20% moving from 2.7 to 3.4. I believe 3.5 made some slight further improvements.
    - BuckRogers 10y ago
      If only CPython3 wasn't completely blown out of the water by Python2's production-ready PyPy. That said, my tests are the exact opposite of what you're claiming- I've been doing the same benchmarks on all the CPython3 releases since 3.2. I think you're the only person I've heard make that claim in fact.
stesch 10y ago
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."
- unlinker 10y ago
  That's a good point despite the downvotes. If you don't need any of the Python 3 goodies, by upgrading you will make your code run even slower. Hard to justify.
  - takeda 10y ago
    If you care this much about performance, python is most likely wrong language for you, you should try statically typed languages instead.
- dec0dedab0de 10y ago
  The people who really decide what you do don't care about syntax. Some bosses care about syntax, at least if you phrase it as maintainability.
Animats 10y ago
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. Stop von Rossum before he kills again. [1] http://www.gossamer-threads.com/lists/python/python/1187134 http://www.gossamer-threads.com/lists/python/python/1187134
- cvwright 10y ago
  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!" Beatings will continue until morale improves...
  - dijit 10y ago
    GIL is a design decision for the interpreter, not a caveat of the language itself. The reference implementation of most compilers/interpreters is usually the slowest one, because it has to be legible to read the code.
  - Animats 10y ago
    The global interpreter lock is the price paid for being able to monkey-patch code and objects from one thread while they are being used in another. That falls out of the original CPython interpreter, which is a naive interpreter in which everything is a dictionary. It would be "un-Pythonic" to change that.
jedberg 10y ago
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.
- SiVal 10y ago
  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.
  - jedberg 10y ago
    I'm not too worried -- we write all our code with Python 3 in mind (and import future) so the transition will be easy. It's just frustrating when I can't take advantage of some of the newer language features.
- rcpt 10y ago
  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 https://github.com/GoogleCloudPlatform/gsutil/issues/29
- edwinyzh 10y ago
  Yes, few days ago I checked AWS Lambda, it clearly only supports Python 2.7, but not Python 3. I understand your worry, which is realistic.
carlsborg 10y ago
Its hard. Imagine you are a Fortune100 company with a 3 Million line code base running critical financial systems off a python 2.7 application framework...
- phonon 10y ago
  Bank of America?
- natch 10y ago
  Not so long ago they were saying this about COBOL. When there is a competitive advantage to adopt the latest best practices, they will. Maybe not this year, but the day will come when even the legacy python developers will jump.
0xADEADBEE 10y ago
- [ ] I've been developing with Python 2 for 8 years now, and I take umbridge at the upgrade. Python 3 introduces a variety of breaking changes but in contrast to other comments, this is great. Python 2 has a litany of mistakes in it (ever try a listcomp using a previously declared variable name as the intermediary? Watch that get clobbered when block-level scoping decides it doesn't fancy it; there are many more similar examples), some of which are mercifully fixed in 3. For me though, what's the point? I like that lru_cache is a convenient decorator rather than having to roll my own memoisation and that some relatively solid steps have been made towards async programming but that's about it. Its not like the changes were things that couldn't be achieved before (Twisted is solid, from what I have seen so far). I still have to factor in the GIL if I want performance to a certain point (dual core processors have been around for almost two decades now - I am starting to question why cPython is even considered a serious choice for use cases where prod has more than one core). More crucially though? The APIs. camelCase features heavily (in spite of PEP8), the principle of most surprise is rampant (I recall last week discovering a function signature with infinite arity rather than passing a collection, like, you know, every other Python method) and SO many more warts. When interacting with a file, try and guess what you want: "readlines? Doesn't load each line into collection, which is what you'd expect. writeline? Be sure to manually interpolate a \n because in contrast to the name, it's actually going to insert everything on the same line because... well, who knows. writelines? Well, you know how in Python you usually iterate over over thing and handle it? Well here, you pass a collection. There's a corresponding read meth... No there isn't". If we're introducing breaking changes, how weren't these things fixed? You either commit to breaking changes or you don't make any - py3 trod the line somewhere in the middle and is paying for it with its adoption numbers. The broader point is that this mess is exactly why we all love libraries like requests. If Python were a Fortune 500 company, GvR would have been ousted as CEO long ago, and rightly so. As a contractor, I have to absorb this new way of doing things in case I find a job that actually requires Py3 knowledge (in the UK at least, these are less frequent than HN prefers to make out) because my marketability depends on it. That said, although I'm currently contributing to Pypy, I realistically see my future in Clojure, Ruby, Elixir or some other language that I'm prepared to put the time into picking up, in contrast to Py3, where I see missteps and hamstrung APIs as active disincentivisation to my learning. Any half decent dev will just move on, because why would they put up with this? Did we not learn anything from PHP?
green_lunch 10y ago
I finally was able to start new projects in Python 3 because most major libraries are compatible.
transpy 10y ago
For us beginners, professionals from other areas that want to use Python as an additional tool, this situation is quite confusing. I'm doing Python MOOCs and most of them focus on Python 2. I don't have a massive code base to maintain like most of you, I just would like to know what path to follow, Py2 or jump already to Py3.
- Alex3917 10y ago
  Just import everything from the __future__ package at the top of each file when writing code. If you do that, any project you create won't take more than a day or two to upgrade to Python 3, so even though it's confusing you don't really need to think much about it until you're ready to upgrade. http://python-future.org/imports.html http://python-future.org/imports.html Basically don't worry about the MOOCs being in Python 2, the differences are trivial and you don't really need to understand them to be going down the right path.
- mkesper 10y ago
  Python3, that can be no question. Python2 is a dead end.
- SiVal 10y ago
  There are old, but still good and sometimes best, learning materials for all mainstream languages. That creates a challenge for learners, because learners should be focusing on the future of the language, not its past. If you're learning C++ now, you really should be learning the C++1x style of writing it; if you're learning JavaScript, it should be ES6-style; and if you're learning Python, it should be Python 3. The older styles of these languages are still relevant to those who will need them for professional use on older code bases, but for a new user, they can be treated as more advanced material to be learned primarily for recognition but not for writing. Learn Python 3 now; add some Python 2 details later, if needed. And if you really love your Python 2 MOOC, go ahead and use it as an introduction. Almost everything they are showing you is both Python 2 AND Python 3, so you're learning Python 3. Then move on to intermediate-level material that is Python 3 and goes into a lot more detail, and you'll easily switch over.
- welder 10y ago
ismdubey 10y ago
You know what will make the transition faster ? Amazon. Reasoning below. Developers care about building things (not talking about core python team but app developers like you and me). Most of them use AWS linux and by default it comes with Python 2. This is why most of the developers keep using python 2.69 or 2.7. If AWS Linux by default changes to Python 3, the game will change. In my view, better petition Amazon to do it :)
ismdubey 10y ago
You know what will make the transition faster ? Amazon. Reasoning below. Developers care about building things (not talking about core python team but app developers like you and me). Most of them use AWS linux and by default it comes with Python 2. This is why most of the developers keep using python 2.69 or 2.7. If AWS Linux by default changes to Python 3, the game will change. In my view, better petition Amazon to do it :)
noobiemcfoob 10y ago
Is this really still so much of an issue? I switched to Python 3 some years ago and haven't even considered going back. I can't say I've come across an issue caused by an incompatibility between the two since the first couple months after switching...
- dkarapetyan 10y ago
  You must be in a very luxurious position then to not have to work with any legacy code base. The reality is that there are some giant python 2.7 code bases with forked versions of some major frameworks and libraries. There's no way in hell these places are going to migrate to Python 3 any time in the next decade.
rjurney 10y ago
What an idiotic idea. Python 3 needlessly broke things for features that did not really improve the language. Python 3 is a dead end. The 'slated' end of 2.7 won't happen, just the project leadership will change.
carapace 10y ago
Please stop working so hard to piss in my soup. I plan to keep using Python 2.* until the sun grows cold or I die (whichever comes first.) So this entire effort seems like a busybody with nothing better to do working hard to screw me over. Knock it off!
dendory 10y ago
Guess it's luck that I started using Python when they released 3, and went straight for that!
njharman 10y ago
Python 2 is not only legacy it is deprecated.
PunchTornado 10y ago
I don't think the same issue will happen to with PHP7 because PHP7 offers performance improvements. When talking to management or client it is useless to name any design improvements, but as soon as you mention speed they will say "yes, let's do it". The issue with Python 3 is that the performance is not that much better.
jamwt 10y ago
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.
overgard 10y ago
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.
kinkdr 10y ago
And this exactly is the beauty of free software. The core team is free to drop support or do whatever they want. One thing they cannot force people to upgrade. They will upgrade when they want to upgrade. Personally I tried upgrading a couple of times, but partial or no support of Python 3 from libraries I depended on, stopped me from doing it.
nurettin 10y ago
> the fact that 1/2 gives 0 in Python 2 has historically been a major source of frustration for new users. Yes. Imagine the bewildering inconsistency when a newcomer who tried any of pascal, c or a myriad of other languages try their hand in python.
dkarapetyan 10y ago
Basically this is an excellent case study of how not to do a major migration from one version of a language to another. There is no way in hell places that have forked versions of libraries and frameworks like django are going to move to python 3, ever.
SFJulie 10y ago
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.

227 points by ngoldbaum 10y ago

skizm 10y ago

It is pretty simple: when I spin up an EC2 instance on amazon, and I type "python" in the console, whatever version that is will be the version I use.

lima 10y ago
Nowadays, I no longer use the distribution Python at all. Debian Stable and pyenv it is. That way, I have a rock solid operating system and my application are completely decoupled. Using distribution packages for application deployments is insane. It makes sense for workstation or systems software where the application you develop is part of the operating system, but for a server application, it makes no sense at all.
- snuxoll 10y ago
  I use distribution packages for all my deployments, period. I have no desire to maintain a separate system for installing an upgrading my own applications versus those provided in repositories already. Time to push out a new release? `tito release koji-el7`, SRPM built and sent to Koji to be built and packaged, every 15 minutes mash runs to update our internal yum repo from Koji - and next time Puppet runs the package is automatically upgraded to the latest version without me having to do anything. No virtualenv's, no tarballs, nothing special beyond an RPM. I won't deploy software any other way (and if something doesn't already have an RPM I will make one for it).
  - kstrauser 10y ago
    Note to self: snuxoll likes pushing boulders up hills by ignoring all the tooling people have invented to make this stuff easy.
    - snuxoll 10y ago
      > ignoring all the tooling people have invented to make this stuff easy. I don't, I just use the standard one that comes with the operating system instead of insisting on re-inventing the wheel because "packaging is hard". I could have just had tito push directly to a yum repository if I so desired, but it's much nicer to use Koji (which I'm already familiar with).
      - kstrauser 10y ago
        > I don't, I just use the standard one that comes with the operating system ...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems: 1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.
        snuxoll 10y ago
        virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path. Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both. Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).
        10y ago
  - takeda 10y ago
    https://ius.io/ https://ius.io/ is your friend. Among many things you have all versions of python available that don't conflict with system packages or themselves. What's awesome is that you can install multiple versions and all of them just work.
- matt_wulfeck 10y ago
  They aren't completely decoupled. Even with a virtenv you still need to install and maintain a lot of library and header packages on the host OS.
  - lima 10y ago
    Well, almost completely. The build dependencies don't change nearly as fast as the application, and are generally backwards compatible.
  - Filligree 10y ago
    For complete decoupling, better use NixOS.
    - lima 10y ago
      Or Docker containers :-)
  - takeda 10y ago
    That's problem which is solved with wheels.
- mixmastamyk 10y ago
  No sense? What if you are happy with the current version and don't plan on changing it before changing the OS? What if you don't install more than one app on a system, or are using containers? Then you might not need the extra complexity.
  - klodolph 10y ago
    Even then. Suppose you want to change the OS for some reason. LTS eventually ends, maybe you want to change out some common library, or whatever. It's nice to have the option.
    - mixmastamyk 10y ago
      You could do it when you need it, ala YAGNI.
sp332 10y ago
Is it that much more work to type "python3" ?
- dyeje 10y ago
  What's the incentive? How discoverable is that? As someone not familiar with Python, I certainly would never guess to type 'python3'.
  - deleted 10y ago
    [deleted]
  - sp332 10y ago
    Python 2 and python 3 are not the same language. There are big breaking changes between them. Most distros kept "python" pointing at python 2 to avoid breaking old scripts. If you want Python 3, you have to ask for it.
    - xapata 10y ago
      Yes, there is a breaking change. No, they are still essentially the same language.
      - sp332 10y ago
        I mean it's a different binary with a different interpreter.
  - mixmastamyk 10y ago
    If you are not familiar with it, why are you running the interactive interpreter? If you are running someone else's script, they will have chosen python3 for you if it is a requirement.
  - zokier 10y ago
    Distros are dropping/have dropped python2 from default install. So incentive is that py3k is available out-of-the-box while you need to install py2 separately. As for discoverability, typing pyt<tab><tab> is probably what most people would do and that discovers python3 just fine.
d0m 10y ago
You still need to pick your linux distro.. and they aren't all running the same version. E.g. archlinux symlinks python to python3.
johnny22 10y ago
python will probably always run python2. if you wanna see if python3 is installed, then type python3.

wyldfire 10y ago

> 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.

irremediable 10y ago
I think part of the "surprise" comes from Python being so versatile. I mostly use it for prototyping numerical programming in a research setting, i.e. like MATLAB. So I'm occasionally surprised by the integer division stuff, because I want to just treat my numbers as numbers and be done with it. OTOH, when I'm doing systemsy stuff, it doesn't surprise me at all.
ufo 10y ago
The integer division is more surprising in a dynamic language because it might stay undetected until the day you happen to pass round numbers to your function.
- wyldfire 10y ago
  I don't think you're correct. If you, the designer, made those operands, you should expect them to be int() or float() because of how you created them. int() and float() have lots of other differences beyond just how they're treated by division.
  - Thrymr 10y ago
    "you, the designer" may not have created the operands, just taken them as function arguments. Sure, you should have written tests for different types of input, but if you didn't, it may surprise you later.
  - 10y ago

rahiel 10y ago

> 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.

nas 10y ago
If you think Python 2.x support ends when the core team stops supporting it, you haven't been studying history. Programming platforms with large code bases (e.g. Cobol, Fortran) have extremely long lifetimes. What's more expensive: 1) porting millions (possibily billions) of lines of working Python 2.x code to Python 3 2) keeping the Python 2.7.x interpreter in deep maintenance mode? This idea that you can force people to move to Python 3 keeps coming up and is misguided, IMHO. There are two proper solutions to this issue: 1) make it easier to port from 2.x to 3.x. We are still making progress. Python 3.5 includes %-style formatting for byte strings. Allowing 'u' as a prefix for strings was another example. Practicality beats purity. 2) make 3.x a more compelling platform for new development. The amount of goodies in 3.0 was pretty underwhelming. I certainly wasn't very excited about moving to it. Async IO is a neat feature. Keep them coming.
- bjt2n3904 10y ago
  This is the problem with Python 3. The arrogance of the people in support of wrestling it from us. > Frankly, if these "carrots" haven't convinced you yet, then I'll wager you're not really the sort of person who is persuaded by carrots. As someone that uses Python as a C replacement for one-off-scripts that work with binary objects and pure ASCII, Unicode is not a carrot. Unicode will never be a carrot. If anything, Unicode keeps me away. If I was developing web apps, GUI programs, or data processing libraries, sure. These would all be carrots. But I'm not. The simplicity of Python 2 is my carrot. > Python 3 does have carrots, and I want them. You have them. But you seem to be more interested in taking away my carrots, so you don't have to worry about them any more. That's arrogance.

BuckRogers 10y ago

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.

daveguy 10y ago
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).
- yeukhon 10y ago
  Proof that there is no performance improvement? There are some changes in PY3 making CPython more performant in some areas, but in some other areas PY3 may perform worse. There was a PyCon talk about this a few years back.
  - daveguy 10y ago
    I haven't seen any proof there is a performance improvement. The only comprehensive benchmarks I have seen show on par or worse performance. If you are going to improve the performance of something I think it is on the "improved" system to demonstrate an improvement.

melling 10y ago

There's a yearly discussion about moving from Python 2 to 3. https://news.ycombinator.com/item?id=8730156 https://news.ycombinator.com/item?id=8730156 https://news.ycombinator.com/item?id=7005711 https://news.ycombinator.com/item?id=7005711 It's not a very productive use of time.

rcarmo 10y ago
I thought it was monthly. Seems to happen around the 20th each time, every time a Python piece gets posted...

Bromskloss 10y ago

I want Python 4 already!

noisy_boy 10y ago

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.

rspeer 10y ago
Interestingly, Django is one of the big projects that has already announced they're dropping Python 2 support before 2020. Django 1.11, to be released in April 2017, is scheduled to be the last version to support Python 2. [1] They've prudently made their last Py2 release a long-term support release, but if you want new Django features after December 2017, you're going to be using Python 3. Django works great on Python 3, BTW, and if you've got plugins that haven't updated, I would recommend being a bit suspicious of their code quality. [1] https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
- 0xADEADBEE 10y ago
  If it helps anyone, 1.8 works with 2.7 and was an LTS release, which is supported until April 2018. You don't get the cool new features like Channels out of the box, but they're available via third parties.
AdamN 10y ago
I started a new project in Django recently and Python3 was obviously the choice. The nice thing is that if a library doesn't support Python3 then it's a good smell that it's bloated (or 'mature') and worth finding a replacement for. Sadly, many legacy Django packages are basically losing steam and shouldn't be used.

21 10y ago

I've seen this story happen twice before. 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.

takeda 10y ago
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.
ash 10y ago
> 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. 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 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/eba9b2f7980f400f6287 https://gist.github.com/dutc/2866d969d5e9209d501a https://gist.github.com/dutc/2866d969d5e9209d501a

nelmaven 10y ago

This sort of war between Python 2 and Python 3 is why I never looked seriously into Python. I don't know where should I start.

esaym 10y ago
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?)
mixmastamyk 10y ago
Python 3.5, installed by default on LTS distributions, and available everywhere else.
- esaym 10y ago
  Python 3.6
  - mixmastamyk 10y ago
    No, still in alpha. If you're just tinkering, sure.
- 10y ago

jtchang 10y ago

I am so annoyed at Python for not having a good upgrade path with backwards compatibility. Even with iOS you can use Swift code along with ObjC.

xapata 10y ago
I haven't had trouble upgrading. What issues are you encountering?
- stesch 10y ago
  No web2py for Python 3.
  - _asummers 10y ago
    I took parallel algorithms with the guy that wrote that framework. Interesting to see it pop up on HN.
- jhasse 10y ago
  SCons not supporting Python 3.
- joobus 10y ago
  Twisted doens't support py3.
  - reubano 10y ago
    That's only half true [1] [1] https://github.com/twisted/twisted/blob/twisted-16.2.0/twisted/python/dist3.py https://github.com/twisted/twisted/blob/twisted-16.2.0/twist...

TorKlingberg 10y ago

Is there any reasonable measurement of Python 3 market share? I guess it's still <25%.

BuckRogers 10y ago
It's tough to know but I keep an eye on this stuff. You can count on a solid ~10% marketshare for Python3. Going too far beyond that without updated numbers would be overly generous. Roughly 12% of PyPi has been ported to Python3[0] and about 10% of pip downloads are Python3[1]. [0]https://youtu.be/G-uKNd5TSBw?t=1m14s https://youtu.be/G-uKNd5TSBw?t=1m14s [1]https://twitter.com/dstufft/status/687663858408919042 https://twitter.com/dstufft/status/687663858408919042
- kstrauser 10y ago
  More importantly (to me) is that Py3 uploads have now exceeded Py2, according to https://twitter.com/chupapuma/status/730088983586181120 https://twitter.com/chupapuma/status/730088983586181120
  - BuckRogers 10y ago
    I saw that one too but Py3 hasn't actually intersected with Py2 yet. Uploads will level off. It doesn't have relevance on a marketshare question, it would be misleading. It does show some momentum. Most everything you would want already exists on Python2. A lot of those uploads are forks or new projects that already have solutions in 2. I have no problem with Python3 and glad to see people putting their money where their mouth is and 'get to porting'. Rather than blogs/complaining about the userbase/backroom deals and conspiracies to kill Python2.
theseatoms 10y ago
What do you mean by "market" in this context? Percentage of firms using either? Or do you just mean SLOC?
karim 10y ago
No there isn't. People used to be able to extrapolate it from the pypi downloads stats (like this: https://alexgaynor.net/2014/jan/03/pypi-download-statistics/ https://alexgaynor.net/2014/jan/03/pypi-download-statistics/), but sadly it's not possible anymore.

pnathan 10y ago

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. :)

RussianCow 10y ago
> 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.
- jdimov9 10y ago
  Elixir _is_ the correct answer. Not sure what you mean by "narrow focus" - it is as general purpose as anything. Only thing holding me back from fully moving from Python to Elixir is that the ecosystem isn't mature enough yet.
  - zeemonkee3 10y ago
    I like Elixir, but the ecosystem has years of catching up to be anywhere close to Python. Not just libraries but experienced developers. There's also a danger it might end up like Ruby - basically the support system for a web framework.
    - true_religion 10y ago
      Elixir is nice, but I hardly think it compares to Python due to the fact that you are required to hand back control from a native call approximately every half second or so or else you will screw the internal scheduler on the ErlangVM.
  - 10y ago

incepted 10y ago

I have a feeling that by the time this happens, a lot of the Python developers will have moved to Go or some other language.

metalliqaz 10y ago

I'll transition when pypy transitions.

reubano 10y ago
http://doc.pypy.org/en/latest/release-pypy3-2.4.0.html http://doc.pypy.org/en/latest/release-pypy3-2.4.0.html
- BuckRogers 10y ago
  It's well-known that PyPy3 is not production-ready. I've spoken with them about this many times over the years and it's not being worked on like PyPy5 is.

kstrauser 10y ago

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.

albasha 10y ago
Which framework are you using for the said microservice?
- kstrauser 10y ago
  Flask + Flask-RESTful for this one.

hartator 10y ago

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.

kstrauser 10y ago
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.
- iak8god 10y ago
  And use __future__ to force yourself not to forget: https://docs.python.org/2/library/__future__.html https://docs.python.org/2/library/__future__.html
ta_389ty4 10y ago
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.
Karunamon 10y ago
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.
pmorici 10y ago
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.
- nomel 10y ago
  Why not have "print thing" to "print(thing)" just be an automatic conversion though?

danso 10y ago

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). [0] http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-ruby-1-9/ http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-r...

Freaky 10y ago
Ruby 1.9 rewarded your upgrade efforts by running twice as fast. There was a lot of enthusiasm to migrate. Python 3 still seems to reward you by running slightly slower. Where's the hook? Marginal improvements to language design are bit of a weak sell for a language that's already pretty nice.
- wbond 10y ago
  All of the testing I've done with real-world code has shown an improvement of 10-20% moving from 2.7 to 3.4. I believe 3.5 made some slight further improvements.
  - BuckRogers 10y ago
    If only CPython3 wasn't completely blown out of the water by Python2's production-ready PyPy. That said, my tests are the exact opposite of what you're claiming- I've been doing the same benchmarks on all the CPython3 releases since 3.2. I think you're the only person I've heard make that claim in fact.

stesch 10y ago

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."

unlinker 10y ago
That's a good point despite the downvotes. If you don't need any of the Python 3 goodies, by upgrading you will make your code run even slower. Hard to justify.
- takeda 10y ago
  If you care this much about performance, python is most likely wrong language for you, you should try statically typed languages instead.
dec0dedab0de 10y ago
The people who really decide what you do don't care about syntax. Some bosses care about syntax, at least if you phrase it as maintainability.

Animats 10y ago

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. Stop von Rossum before he kills again. [1] http://www.gossamer-threads.com/lists/python/python/1187134 http://www.gossamer-threads.com/lists/python/python/1187134

cvwright 10y ago
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!" Beatings will continue until morale improves...
- dijit 10y ago
  GIL is a design decision for the interpreter, not a caveat of the language itself. The reference implementation of most compilers/interpreters is usually the slowest one, because it has to be legible to read the code.
- Animats 10y ago
  The global interpreter lock is the price paid for being able to monkey-patch code and objects from one thread while they are being used in another. That falls out of the original CPython interpreter, which is a naive interpreter in which everything is a dictionary. It would be "un-Pythonic" to change that.

jedberg 10y ago

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.

SiVal 10y ago
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.
- jedberg 10y ago
  I'm not too worried -- we write all our code with Python 3 in mind (and import future) so the transition will be easy. It's just frustrating when I can't take advantage of some of the newer language features.
rcpt 10y ago
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 https://github.com/GoogleCloudPlatform/gsutil/issues/29
edwinyzh 10y ago
Yes, few days ago I checked AWS Lambda, it clearly only supports Python 2.7, but not Python 3. I understand your worry, which is realistic.

carlsborg 10y ago

Its hard. Imagine you are a Fortune100 company with a 3 Million line code base running critical financial systems off a python 2.7 application framework...

phonon 10y ago
Bank of America?
natch 10y ago
Not so long ago they were saying this about COBOL. When there is a competitive advantage to adopt the latest best practices, they will. Maybe not this year, but the day will come when even the legacy python developers will jump.

0xADEADBEE 10y ago

- [ ] I've been developing with Python 2 for 8 years now, and I take umbridge at the upgrade. Python 3 introduces a variety of breaking changes but in contrast to other comments, this is great. Python 2 has a litany of mistakes in it (ever try a listcomp using a previously declared variable name as the intermediary? Watch that get clobbered when block-level scoping decides it doesn't fancy it; there are many more similar examples), some of which are mercifully fixed in 3. For me though, what's the point? I like that lru_cache is a convenient decorator rather than having to roll my own memoisation and that some relatively solid steps have been made towards async programming but that's about it. Its not like the changes were things that couldn't be achieved before (Twisted is solid, from what I have seen so far). I still have to factor in the GIL if I want performance to a certain point (dual core processors have been around for almost two decades now - I am starting to question why cPython is even considered a serious choice for use cases where prod has more than one core). More crucially though? The APIs. camelCase features heavily (in spite of PEP8), the principle of most surprise is rampant (I recall last week discovering a function signature with infinite arity rather than passing a collection, like, you know, every other Python method) and SO many more warts. When interacting with a file, try and guess what you want: "readlines? Doesn't load each line into collection, which is what you'd expect. writeline? Be sure to manually interpolate a \n because in contrast to the name, it's actually going to insert everything on the same line because... well, who knows. writelines? Well, you know how in Python you usually iterate over over thing and handle it? Well here, you pass a collection. There's a corresponding read meth... No there isn't". If we're introducing breaking changes, how weren't these things fixed? You either commit to breaking changes or you don't make any - py3 trod the line somewhere in the middle and is paying for it with its adoption numbers. The broader point is that this mess is exactly why we all love libraries like requests. If Python were a Fortune 500 company, GvR would have been ousted as CEO long ago, and rightly so. As a contractor, I have to absorb this new way of doing things in case I find a job that actually requires Py3 knowledge (in the UK at least, these are less frequent than HN prefers to make out) because my marketability depends on it. That said, although I'm currently contributing to Pypy, I realistically see my future in Clojure, Ruby, Elixir or some other language that I'm prepared to put the time into picking up, in contrast to Py3, where I see missteps and hamstrung APIs as active disincentivisation to my learning. Any half decent dev will just move on, because why would they put up with this? Did we not learn anything from PHP?

green_lunch 10y ago

I finally was able to start new projects in Python 3 because most major libraries are compatible.

transpy 10y ago

For us beginners, professionals from other areas that want to use Python as an additional tool, this situation is quite confusing. I'm doing Python MOOCs and most of them focus on Python 2. I don't have a massive code base to maintain like most of you, I just would like to know what path to follow, Py2 or jump already to Py3.

Alex3917 10y ago
Just import everything from the __future__ package at the top of each file when writing code. If you do that, any project you create won't take more than a day or two to upgrade to Python 3, so even though it's confusing you don't really need to think much about it until you're ready to upgrade. http://python-future.org/imports.html http://python-future.org/imports.html Basically don't worry about the MOOCs being in Python 2, the differences are trivial and you don't really need to understand them to be going down the right path.
mkesper 10y ago
Python3, that can be no question. Python2 is a dead end.
SiVal 10y ago
There are old, but still good and sometimes best, learning materials for all mainstream languages. That creates a challenge for learners, because learners should be focusing on the future of the language, not its past. If you're learning C++ now, you really should be learning the C++1x style of writing it; if you're learning JavaScript, it should be ES6-style; and if you're learning Python, it should be Python 3. The older styles of these languages are still relevant to those who will need them for professional use on older code bases, but for a new user, they can be treated as more advanced material to be learned primarily for recognition but not for writing. Learn Python 3 now; add some Python 2 details later, if needed. And if you really love your Python 2 MOOC, go ahead and use it as an introduction. Almost everything they are showing you is both Python 2 AND Python 3, so you're learning Python 3. Then move on to intermediate-level material that is Python 3 and goes into a lot more detail, and you'll easily switch over.
welder 10y ago

ismdubey 10y ago

You know what will make the transition faster ? Amazon. Reasoning below. Developers care about building things (not talking about core python team but app developers like you and me). Most of them use AWS linux and by default it comes with Python 2. This is why most of the developers keep using python 2.69 or 2.7. If AWS Linux by default changes to Python 3, the game will change. In my view, better petition Amazon to do it :)

ismdubey 10y ago

noobiemcfoob 10y ago

Is this really still so much of an issue? I switched to Python 3 some years ago and haven't even considered going back. I can't say I've come across an issue caused by an incompatibility between the two since the first couple months after switching...

dkarapetyan 10y ago
You must be in a very luxurious position then to not have to work with any legacy code base. The reality is that there are some giant python 2.7 code bases with forked versions of some major frameworks and libraries. There's no way in hell these places are going to migrate to Python 3 any time in the next decade.

rjurney 10y ago

What an idiotic idea. Python 3 needlessly broke things for features that did not really improve the language. Python 3 is a dead end. The 'slated' end of 2.7 won't happen, just the project leadership will change.

carapace 10y ago

Please stop working so hard to piss in my soup. I plan to keep using Python 2.* until the sun grows cold or I die (whichever comes first.) So this entire effort seems like a busybody with nothing better to do working hard to screw me over. Knock it off!

dendory 10y ago

Guess it's luck that I started using Python when they released 3, and went straight for that!

njharman 10y ago

Python 2 is not only legacy it is deprecated.

PunchTornado 10y ago

I don't think the same issue will happen to with PHP7 because PHP7 offers performance improvements. When talking to management or client it is useless to name any design improvements, but as soon as you mention speed they will say "yes, let's do it". The issue with Python 3 is that the performance is not that much better.

jamwt 10y ago

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.

overgard 10y ago

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.

kinkdr 10y ago

And this exactly is the beauty of free software. The core team is free to drop support or do whatever they want. One thing they cannot force people to upgrade. They will upgrade when they want to upgrade. Personally I tried upgrading a couple of times, but partial or no support of Python 3 from libraries I depended on, stopped me from doing it.

nurettin 10y ago

> the fact that 1/2 gives 0 in Python 2 has historically been a major source of frustration for new users. Yes. Imagine the bewildering inconsistency when a newcomer who tried any of pascal, c or a myriad of other languages try their hand in python.

dkarapetyan 10y ago

Basically this is an excellent case study of how not to do a major migration from one version of a language to another. There is no way in hell places that have forked versions of libraries and frameworks like django are going to move to python 3, ever.

SFJulie 10y ago

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.