8 ms·

Updated Packages – Python 3.3

135 points by Goranek 14y ago

ancarda 14y ago
I don't code Python so as an outsider it always seemed strange that almost all code was written for Python 2.x - like 3 was unanimously rejected from the community. Can anyone shed light on why this is/was the case?
- taude 14y ago
  Tons of changes in 3 making it backwards incompatible + nearly 20 years of legacy Python libraries
- misnome 14y ago
  All code WAS written for 2.X, because 3 was either not around yet, under constantly changing flux (before release proper, and to a certain extent for a couple of versions) or the subsequent killer: Not enough libraries that you might depend on, worked in 3.0 yet - as it was written to be deliberately incompatible by removing legacy and old ways of doing things. IIRC most of the big packages have finally moved over so it'll just become less of an issue over time.
  - oracuk 14y ago
    Is there a clear list anywhere of which major packages have and haven't moved over to Python 3 yet? Edit: I found one here https://python3wos.appspot.com/ https://python3wos.appspot.com/ and another one here http://py3ksupport.appspot.com/ http://py3ksupport.appspot.com/ Looking forward to NLTK 3.0.
    - smoyer 14y ago
      That's the one I watch ... it's a lot greener today than it was 2 years ago.
      - masklinn 14y ago
        IIRC it became the "Wall of SuperPowers" (from its former Wall of Shame) — indicating more than 50% of tracked packages being P3 compatible — around mid-december 2012.
      - oracuk 14y ago
        There's been a real change, even from 6 months ago when I last considered Python 3.0. Apart from NLTK (A port is underway) everything I use currently has been ported which was a surprise. Time to start thinking about making the move I think.
        sigzero 14y ago
        Guido put out a 5 year transition plan. I think we are coming to the tail end of that and now the move is happening to Python 3.
- mtct 14y ago
  Well, nothing new. In Java a lot of code is still written for Java 6. C++11 is not even fully supported from compilers And Windows Xp still have more than 30% of market share.
  - jhawthorn 14y ago
    Difference being that new versions of java, windows, c++ compilers work with the existing software.
    - PommeDeTerre 14y ago
      That comes at a cost, though. The implementations become more complex, which in turn can result in bugs, development delays, and so forth. Additionally, it allows users of said technologies to continue to use techniques and functionality that have been observed to be outdated, bad or even harmful. You mention Java, which is a good example of how cruft can linger for many, many years, and continue to be used in that time.
      - jhawthorn 14y ago
        Not saying python 3 should have been compatible with 2. Just that this was not an apt comparison.
  - cpeterso 14y ago
    Is there Java 6 code that is not forward-compatible with Java 7?
- FooBarWidget 14y ago
  As a Rubyist it also seemed strange to me. As soon as Ruby 1.9 became stable, it was embraced by the community fairly quickly. Ruby 2.0 has only been out for a month and there are already projects that require 2.0. In contrast, Python 3 adoption still isn't finished, and Python 3 has been around for several years longer than Ruby 1.9. I guess that the incompatible changes in Python 3 don't really help. Ruby 1.9 introduced incompatibilities but they were fairly minor and easy to resolve. The biggest incompatibility was probably the introduction of string encodings. Python 3 introduced a stricter string encoding system and changed syntax in some ways. Some of the syntax changes make it very difficult to write code that is compatible with 2.6, 2.7 and 3.0.
  - takluyver 14y ago
    I've heard before that the Ruby community accepts new stuff much quicker than Python. You can make an argument for either attitude being more healthy. Part of it is because Python has become a core part of many Linux distributions, so it was tied to release cycles lasting years. Until quite recently, many packages were supporting Python 2.4, superseded in 2006, so they could be used on RHEL 5 servers. It's actually fairly easy to write code that works with 2.6+ and 3.x, although you do still have to pay attention to it. Supporting 2.5 or below as well makes it rather harder.
  - vidarh 14y ago
    I know several pieces of production code that are still on Ruby 1.8.x. 1.9.x was adopted fairly quickly in some very vocal subsets of the Ruby community, but despite the fact that the incompatibilities are fairly small there are still people that haven't made the migration. Personally I still run 1.8.x several places too, not because I have any particular reason to, but because I haven't had any particular reason to upgrade - not a single gem I depend on for my hobby projects require 1.9.x.
    - damncabbage 14y ago
      One big reason for moving to 1.9 is that 1.8 is hitting EOL in June[1]; this means no further security patches either. (The plan for this was originally announced[2] in 2011.) 1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/47201 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/4... 2. http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/ http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
- eterm 14y ago
  Python 2 and Python 3 are effectively different languages in the way that VB and C# are different languages. Does it seem strange that some people code in VB when C# exists? Python 3 isn't just a little bit incompatible in a few places, it has widespread incompatibilities and is therefore effectively a different language.
  - udp 14y ago
    That's a pretty bad comparison. The differences between VB and C# are much more dramatic than the differences between Python 2 and Python 3.
    - zanny 14y ago
      I dunno, it is kind of reasonable. C# was designed with a different mindset, but the intents were the same - take a predecessor (VB / Python2) and make them more modern, fix the gotchas and mindfuck, and produce something more refined that isn't backwards compatible. C# takes it much further, and iterates on syntax a lot more, but Python3's breakage from Python2's is comparable I feel, just not in nearly as extreme a case.
      - lucian1900 14y ago
        It is trivial to write new projects that work on both Python 2.7 and 3.3. So trivial in fact that I did it without trying to several times.
      - masklinn 14y ago
        > Python3's breakage from Python2's is comparable I feel They're not. You can create "single source" Python packages working on both Python 2 and Python 3. Good luck doing that with C# and VB.
  - alexchamberlain 14y ago
    The comparison may have made more sense with C and C++...
- masklinn 14y ago
  It was not a rejection. Python 3 (project name Python 3000, just to give you the kind of scope we're talking about) was always expected to be a long and rather arduous migration, because it "cleaned up" a number of things in backwards-incompatible manner: the stdlib was reorganized, syntax was added (and removed), semantics altered (the basic string of Python 2 is a bytestring, in Python 3 it's a codepoint sequence and implicit conversions were removed from the language), shuffling between keywords and regular symbols, etc... It might have been even more arduous than the core team expected, but most of the community has been aware it'd take a long time from the start (the initial planning alone took ~30 months: the PEP3000 was created in April 2006 and Python 3.0 was released in December 2008, and as far as I remember Python 3.0 was not considered a production-able Python, more of a "stable" version for experiments and discovery in real-world settings) Things were moving very slowly at the start, some features were backported to Python 2, others were reintroduced (in Python 3.2 and 3.3) and compatibility packages slowly appeared as people started experimenting with porting strategies and methods. Since the second half of 2012, things have started picking up steam as bigger packages have started their migration effort (often as single-source, which is now considered the best strategy when possible) which is starting to solve the chicken-and-eggs problem for end-users (applications can't switch until all their dependencies are compatible)[0]. Python 2 will stick around though, there are 20 years of Python code which won't run as-is on Python 3, and may never do barring significant rewrite. And of course Python 3 may yet be rejected by the community, although it definitely seems to be gaining — rather than losing — steam. The biggest problems in the long term will probably be in the Scientific Python communities. [0] A few pretty big names are still Python 2 though, Werkzeug and Flask are big ones for webby stuff, the official-ish MySQL adapter is an other one for many, and a bunch are not considered "production-ready" state or side-packages are missing e.g. Django 1.5 is the start of Django's transition but many extensions such as South or the debug-toolbar are not p3-compatible.
  - swinglock 14y ago
    How I wish Flask would support Python 3. And gevent, Twisted, PIL, NumPy, PyPy and... can I have gevent and PyPy working together as well? Oh well, back to reality!
- joosters 14y ago
  Can't shed any light on this, just wanted to add a 'me too'. As a perl veteran, I've been meaning to learn Python someday, and I figured I'd wait until the 'new' one became the standard, saving me from worrying about all the random incompatibilities. Maybe I'll only have to wait a few more years! ...makes me wonder if anyone had the opposite thought: A python programmer thinking of learning perl, but waiting until this newfangled perl 6 became the standard. I wonder who'll end up learning a new language first?
  - lrem 14y ago
    For a good start, has Perl 6 finally been released?
    - sigzero 14y ago
      Not in a form that you would use for production, no.
  - elbear 14y ago
    If you want to learn Python, you should jump in. The differences between Python 2 and Python 3 are easy to pick up if you start with Python 2.
  - zanny 14y ago
    As a polyglot whose preferred scripting language is Python, 3 is the future, there will be no more backwards compatibility breakage in it (that was what going to v3 was for) and the only reason major dev houses still don't use it is because legacy 2.7 code isn't / won't be ported, and is backwards incompatible. 3.0 and its usage of pervasive unicode is an essential scripting language feature Python needed, and where Python2 was a syntactically pretty language with some big pitfalls and "wtfs?" Python3 corrects most of those and is all around better for it. I do have to say, as someone who has looked at Perl, that is pretty much my stance - Perl 6 is a long time coming, I want it to hit before I try out Perl, same reason I waited until C++11 was market ready to jump into C++ (and now I'm writing qt apps all the time).
    - 14y ago
- takluyver 14y ago
  It's not exactly rejected by the community - apart from a few vocal critics, I think most people are comfortable with it, and a lot of code does now support it. It's just a slow movement, because there's a lot of legacy code out there. Also, many features up to 3.2 were backported to 2.7, so there was little incentive to make the switch. That's starting to change with 3.3.
- 3pt14159 14y ago
  The best thing about python 3 is that it froze python 2. So right now we have this rock solidly stable python (2.7) and this weird new python (3.x) that not a lot of libraries work with. The point here is that they changed too much in python 3. Basic things like division changed, and many of these changes people disagreed with. People will still be starting projects with 2.7 in 5 years.
  - tshepang 14y ago
    Around 40% of python.org Windows downloads last year were of Python 3[1]. This is for something that is less than 5 years old. What do you think the next 5 years will look like? It will be interesting to watch. [1]: http://blog.briancurtin.com/posts/the-year-of-the-snake.html http://blog.briancurtin.com/posts/the-year-of-the-snake.html
- reidrac 14y ago
  I don't think it's about "rejection" but a practical thing. When starting a project you may need some 3rd party stuff (library, framework, etc) that doesn't support Python 3 (yet; for different reasons, sometimes the project is unmaintained, sometimes is a _huge_ project and Python 3 support is not ready, but I have yet to find a project that "rejects" Python 3). Because 2.x (2.6 to 2.7) is available, it's not a big deal and you just use Python 2. Thanks to 2.7 (that includes several features from Python 3), finally moving to Python 3 shouldn't be a pain for most people, once all your requirements support Python 3.
- kzrdude 14y ago
  Not easy to port pyGTK projects at all -- they didn't release until long after python 3's first release, and also combined the bump with a step to GTK3 and a different technology for the langauage bindings (gobject-introspections). Sure, all those three new things are better, but each of them add up to porting a complex app.
  - takluyver 14y ago
    The best way is to get your application working with gobject-introspection and GTK3 on Python 2 first. Then it's very easy to port to Python 3.
taude 14y ago
Interesting. Maybe as the push to Python 3 gets more forced, more active-legacy code will be upgraded?
- joemaller1 14y ago
  Let's hope so, there's got to be a tipping point.
agung17 14y ago
thank you for the information, because I was new about the language of programmers in the world of IT http://www.obatkuatpria-pelangsing.com/ http://www.obatkuatpria-pelangsing.com/
smoyer 14y ago
I like Python, but keeping both 2 and 3 alive for so long has caused problems that make it hard to justify for serious projects. What will your boss decide when half his developers say that the two branch is right for a task and half say the three branch should be used? He'll pick another language. I'm not sure I'm willing to trust Ubuntu to decide this for me ... they also thought Unity was in my best interest, and foisted the Amazon store upon my desktop. Good luck Ubuntu ... I'm outta here.
- ed_blackburn 14y ago
  I've worked in environments where classic ASP, .NET 1.0, .NET 3.5 and 4.0 are all in production, some on the same server. I imagine there are similar tales regarding production environments for Java and Ruby etc. If you cannot run different versions simultaneously you have a problem. Thankfully you can.
- andrewcooke 14y ago
  ubuntu isn't deciding anything for you. both are available as packages. and the decision to introduce python 3 wasn't made by them anyway. for new projects where i control deployment i use python 3 (these days, the support is there - in fact in at least one case i am using a python 3 only lib). for maintenance or projects where the client has existing systems, i use whatever is most appropriate. i am a professional. i get the job done. what more is there to say? oh, yeah, running round throwing a hissy fit for internet points.
- pcx66 14y ago
  I think the way the Python community handled this change is really mature compared to several other communities who've been through such change. They've done great work in making sure one single codebase can support 2.6, 2.7 and 3.2/3, Django does this. Teams using Python to develop, in the present state, mostly base their decisions to chose py2 or py3 based on the maturity of the libraries (py3 ones) they are gonna use. Ubuntu devs are using good judgment here, they are first moving code they use for the OS from 2 to 3 and switch the default python package version. But py2 should be available to any package which specifies it as a dependency. This should be nearly invisible to a normal user. This also gives the much needed push for Py3 adoption.
agung17 14y ago
http://www.obatkuatpria-pelangsing.com/2013/04/vakum-pembesar-penis-handsome-up.html http://www.obatkuatpria-pelangsing.com/2013/04/vakum-pembesa... thank you for the information, because I was new about the language of programmers in the world of IT
rwmj 14y ago
Python 3.3 was added to Fedora in August 2012. Source: http://koji.fedoraproject.org/koji/packageinfo?packageID=9781 http://koji.fedoraproject.org/koji/packageinfo?packageID=978...
- bluedino 14y ago
  Fedora is more of a bleeding-edge (or at least developer-focused) distro - they also ship with Ruby 1.9 instead of 1.8.
  - nXqd 14y ago
    +1 for Fedora :)
  - alexchamberlain 14y ago
    Arch Linux all the way!
  - kokey 14y ago
    Interesting, until last year I used to use Ubuntu when I wanted a bleeding edge and lightweight OS for, say, working with new hardware. How things change.
    - LukeShu 14y ago
      Fedora has always been bleeding edge. In my experience, to the point of being unstable, at least when a version is new (Installed Fedora 15 the day it came out, segfaults galore).
    - yogo 14y ago
      In its lifetime Ubuntu has never been bleeding edge nor lightweight compared to many other distros. I'm an Arch user all the way but I still take other distros for a test drive every so often and it amazes me the crap distros bundle together in packages when so many things could be made to be optional dependencies. I guess it all depends on your standard for lightweight :).
  - 14y ago
stefantalpalaru 14y ago
There's always Linux Mint[1]. [1] http://www.linuxmint.com/about.php http://www.linuxmint.com/about.php
ubersoldat2k7 14y ago
I think it's good that they "force" a little for devs to start using Python3.
d0m 14y ago
Bha, I still believe that's a mistake. Breaking already existing and working tools for the sake of having python3. Thousands of scripts use "python" as default, instead of "python2". They will all break. The problem isn't when it's your own stuff. but mostly when you're using a automatically build system that use "python" somewhere. And then, that thing crashes because it's now expecting python2.. or that the 10 years old package would automatically be ported to python3. As far as I'm concerned, I would have preferred Python to be Python2.x, and a new code name for Python3, i.e. Cobra.
- njharman 14y ago
  If you want to live in the past, don't upgrade. If you want have your cake and eat it too, tough. Everyone else, will upgrade and rejoice that Ubuntu isn't 10 years behind like another CrimsonCap distro.
  - lmickh 14y ago
    The CrimsonCap distro has supported side-by-side Python2 and Python3 for awhile now. There is already a process underway to get the larger components migrated to Python3. Sure the process isn't 100% complete, but it is hardly 10 years behind.
- BCM43 14y ago
  I'm guessing that Debian, if they have not already done it, will start searching packages for ^#/usr/bin/python$, and filing bug reports for packages that match. So that should not be as much of a problem. As for user-created scripts...
- tshepang 14y ago
  Nothing will break (in the sense you mention). Python 2 will remain /usr/bin/python while Python 3 is /usr/bin/python3.
  - d0m 14y ago
    Ha, ok thank you. With archlinux, /usr/bin/python is now linking to /usr/bin/python3..
zurn 14y ago
Previous discussion: https://news.ycombinator.com/item?id=4486608 https://news.ycombinator.com/item?id=4486608 This was around Ubuntu 12.10, references Ubuntu wiki with nearly the same text back then.
levesque 14y ago
Been happily running Ubuntu 13.04 with Python 3.3 for a few weeks. Sure some packages will break, but it will initiate a real migration, and in the end Python3 will be the default Python. All in all, there's no way to make this transition without breaking stuff, it just needs to be done.
antihero 14y ago
Arch has been using Python 3 for quite a long while, now. However, any push that allows us to use 3.3 is a great thing. I've been reading the 3.3 docs and being like, neat feature! Then switching back to the 2.7 docs and realising I can't use it :(
- eliben 14y ago
  Yep, after the feature freeze between 3.1 and 3.2, 3.3 was a significant jump forward.
niggler 14y ago
When will perl6 become the standard perl?
- chimeracoder 14y ago
  Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked. Python 2 is not being developed actively, aside from security updates, so it is permanently frozen at 2.7, with the intent of removing support entirely eventually (though not for a while). It's not really a like comparison to compare the two.
  - lmm 14y ago
    >Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked. It wasn't always that way, however much certain luminaries try to retcon. Perl6 was originally intended to be, well, the next version of perl; it was only after the community's rejection that the decision to continue perl5 happened. It's not beyond the realms of possibility that the same thing could happen to python (though I certainly hope not, and stories like this suggest we're reaching the tipping point).
    - chromatic 14y ago
      it was only after the community's rejection that the decision to continue perl5 happened. The lack of any usable Perl 6 implementation by the time of Perl 5.12 did more to promote the continuation of Perl 5 as its own project than any specific rejection of Perl 6. When the plan was for Perl 6 to replace Perl 5, the idea that Perl 5.12 would migrate to Parrot as a VM so that Perl 5 and Perl 6 code could run in the same process.
- Flimm 14y ago
  From what I've seen, the difference between Perl 5 and 6 is much greater than the difference between Python 2 and 3. For this reason, I have very little hope for Perl 6.
xtc 14y ago
Ubuntu also thinks Unity is a good idea.

135 points by Goranek 14y ago

I don't code Python so as an outsider it always seemed strange that almost all code was written for Python 2.x - like 3 was unanimously rejected from the community. Can anyone shed light on why this is/was the case?

taude 14y ago
Tons of changes in 3 making it backwards incompatible + nearly 20 years of legacy Python libraries
misnome 14y ago
All code WAS written for 2.X, because 3 was either not around yet, under constantly changing flux (before release proper, and to a certain extent for a couple of versions) or the subsequent killer: Not enough libraries that you might depend on, worked in 3.0 yet - as it was written to be deliberately incompatible by removing legacy and old ways of doing things. IIRC most of the big packages have finally moved over so it'll just become less of an issue over time.
- oracuk 14y ago
  Is there a clear list anywhere of which major packages have and haven't moved over to Python 3 yet? Edit: I found one here https://python3wos.appspot.com/ https://python3wos.appspot.com/ and another one here http://py3ksupport.appspot.com/ http://py3ksupport.appspot.com/ Looking forward to NLTK 3.0.
  - smoyer 14y ago
    That's the one I watch ... it's a lot greener today than it was 2 years ago.
    - masklinn 14y ago
      IIRC it became the "Wall of SuperPowers" (from its former Wall of Shame) — indicating more than 50% of tracked packages being P3 compatible — around mid-december 2012.
    - oracuk 14y ago
      There's been a real change, even from 6 months ago when I last considered Python 3.0. Apart from NLTK (A port is underway) everything I use currently has been ported which was a surprise. Time to start thinking about making the move I think.
      - sigzero 14y ago
        Guido put out a 5 year transition plan. I think we are coming to the tail end of that and now the move is happening to Python 3.
mtct 14y ago
Well, nothing new. In Java a lot of code is still written for Java 6. C++11 is not even fully supported from compilers And Windows Xp still have more than 30% of market share.
- jhawthorn 14y ago
  Difference being that new versions of java, windows, c++ compilers work with the existing software.
  - PommeDeTerre 14y ago
    That comes at a cost, though. The implementations become more complex, which in turn can result in bugs, development delays, and so forth. Additionally, it allows users of said technologies to continue to use techniques and functionality that have been observed to be outdated, bad or even harmful. You mention Java, which is a good example of how cruft can linger for many, many years, and continue to be used in that time.
    - jhawthorn 14y ago
      Not saying python 3 should have been compatible with 2. Just that this was not an apt comparison.
- cpeterso 14y ago
  Is there Java 6 code that is not forward-compatible with Java 7?
FooBarWidget 14y ago
As a Rubyist it also seemed strange to me. As soon as Ruby 1.9 became stable, it was embraced by the community fairly quickly. Ruby 2.0 has only been out for a month and there are already projects that require 2.0. In contrast, Python 3 adoption still isn't finished, and Python 3 has been around for several years longer than Ruby 1.9. I guess that the incompatible changes in Python 3 don't really help. Ruby 1.9 introduced incompatibilities but they were fairly minor and easy to resolve. The biggest incompatibility was probably the introduction of string encodings. Python 3 introduced a stricter string encoding system and changed syntax in some ways. Some of the syntax changes make it very difficult to write code that is compatible with 2.6, 2.7 and 3.0.
- takluyver 14y ago
  I've heard before that the Ruby community accepts new stuff much quicker than Python. You can make an argument for either attitude being more healthy. Part of it is because Python has become a core part of many Linux distributions, so it was tied to release cycles lasting years. Until quite recently, many packages were supporting Python 2.4, superseded in 2006, so they could be used on RHEL 5 servers. It's actually fairly easy to write code that works with 2.6+ and 3.x, although you do still have to pay attention to it. Supporting 2.5 or below as well makes it rather harder.
- vidarh 14y ago
  I know several pieces of production code that are still on Ruby 1.8.x. 1.9.x was adopted fairly quickly in some very vocal subsets of the Ruby community, but despite the fact that the incompatibilities are fairly small there are still people that haven't made the migration. Personally I still run 1.8.x several places too, not because I have any particular reason to, but because I haven't had any particular reason to upgrade - not a single gem I depend on for my hobby projects require 1.9.x.
  - damncabbage 14y ago
    One big reason for moving to 1.9 is that 1.8 is hitting EOL in June[1]; this means no further security patches either. (The plan for this was originally announced[2] in 2011.) 1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/47201 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/4... 2. http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/ http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
eterm 14y ago
Python 2 and Python 3 are effectively different languages in the way that VB and C# are different languages. Does it seem strange that some people code in VB when C# exists? Python 3 isn't just a little bit incompatible in a few places, it has widespread incompatibilities and is therefore effectively a different language.
- udp 14y ago
  That's a pretty bad comparison. The differences between VB and C# are much more dramatic than the differences between Python 2 and Python 3.
  - zanny 14y ago
    I dunno, it is kind of reasonable. C# was designed with a different mindset, but the intents were the same - take a predecessor (VB / Python2) and make them more modern, fix the gotchas and mindfuck, and produce something more refined that isn't backwards compatible. C# takes it much further, and iterates on syntax a lot more, but Python3's breakage from Python2's is comparable I feel, just not in nearly as extreme a case.
    - lucian1900 14y ago
      It is trivial to write new projects that work on both Python 2.7 and 3.3. So trivial in fact that I did it without trying to several times.
    - masklinn 14y ago
      > Python3's breakage from Python2's is comparable I feel They're not. You can create "single source" Python packages working on both Python 2 and Python 3. Good luck doing that with C# and VB.
- alexchamberlain 14y ago
  The comparison may have made more sense with C and C++...
masklinn 14y ago
It was not a rejection. Python 3 (project name Python 3000, just to give you the kind of scope we're talking about) was always expected to be a long and rather arduous migration, because it "cleaned up" a number of things in backwards-incompatible manner: the stdlib was reorganized, syntax was added (and removed), semantics altered (the basic string of Python 2 is a bytestring, in Python 3 it's a codepoint sequence and implicit conversions were removed from the language), shuffling between keywords and regular symbols, etc... It might have been even more arduous than the core team expected, but most of the community has been aware it'd take a long time from the start (the initial planning alone took ~30 months: the PEP3000 was created in April 2006 and Python 3.0 was released in December 2008, and as far as I remember Python 3.0 was not considered a production-able Python, more of a "stable" version for experiments and discovery in real-world settings) Things were moving very slowly at the start, some features were backported to Python 2, others were reintroduced (in Python 3.2 and 3.3) and compatibility packages slowly appeared as people started experimenting with porting strategies and methods. Since the second half of 2012, things have started picking up steam as bigger packages have started their migration effort (often as single-source, which is now considered the best strategy when possible) which is starting to solve the chicken-and-eggs problem for end-users (applications can't switch until all their dependencies are compatible)[0]. Python 2 will stick around though, there are 20 years of Python code which won't run as-is on Python 3, and may never do barring significant rewrite. And of course Python 3 may yet be rejected by the community, although it definitely seems to be gaining — rather than losing — steam. The biggest problems in the long term will probably be in the Scientific Python communities. [0] A few pretty big names are still Python 2 though, Werkzeug and Flask are big ones for webby stuff, the official-ish MySQL adapter is an other one for many, and a bunch are not considered "production-ready" state or side-packages are missing e.g. Django 1.5 is the start of Django's transition but many extensions such as South or the debug-toolbar are not p3-compatible.
- swinglock 14y ago
  How I wish Flask would support Python 3. And gevent, Twisted, PIL, NumPy, PyPy and... can I have gevent and PyPy working together as well? Oh well, back to reality!
joosters 14y ago
Can't shed any light on this, just wanted to add a 'me too'. As a perl veteran, I've been meaning to learn Python someday, and I figured I'd wait until the 'new' one became the standard, saving me from worrying about all the random incompatibilities. Maybe I'll only have to wait a few more years! ...makes me wonder if anyone had the opposite thought: A python programmer thinking of learning perl, but waiting until this newfangled perl 6 became the standard. I wonder who'll end up learning a new language first?
- lrem 14y ago
  For a good start, has Perl 6 finally been released?
  - sigzero 14y ago
    Not in a form that you would use for production, no.
- elbear 14y ago
  If you want to learn Python, you should jump in. The differences between Python 2 and Python 3 are easy to pick up if you start with Python 2.
- zanny 14y ago
  As a polyglot whose preferred scripting language is Python, 3 is the future, there will be no more backwards compatibility breakage in it (that was what going to v3 was for) and the only reason major dev houses still don't use it is because legacy 2.7 code isn't / won't be ported, and is backwards incompatible. 3.0 and its usage of pervasive unicode is an essential scripting language feature Python needed, and where Python2 was a syntactically pretty language with some big pitfalls and "wtfs?" Python3 corrects most of those and is all around better for it. I do have to say, as someone who has looked at Perl, that is pretty much my stance - Perl 6 is a long time coming, I want it to hit before I try out Perl, same reason I waited until C++11 was market ready to jump into C++ (and now I'm writing qt apps all the time).
  - 14y ago
takluyver 14y ago
It's not exactly rejected by the community - apart from a few vocal critics, I think most people are comfortable with it, and a lot of code does now support it. It's just a slow movement, because there's a lot of legacy code out there. Also, many features up to 3.2 were backported to 2.7, so there was little incentive to make the switch. That's starting to change with 3.3.
3pt14159 14y ago
The best thing about python 3 is that it froze python 2. So right now we have this rock solidly stable python (2.7) and this weird new python (3.x) that not a lot of libraries work with. The point here is that they changed too much in python 3. Basic things like division changed, and many of these changes people disagreed with. People will still be starting projects with 2.7 in 5 years.
- tshepang 14y ago
  Around 40% of python.org Windows downloads last year were of Python 3[1]. This is for something that is less than 5 years old. What do you think the next 5 years will look like? It will be interesting to watch. [1]: http://blog.briancurtin.com/posts/the-year-of-the-snake.html http://blog.briancurtin.com/posts/the-year-of-the-snake.html
reidrac 14y ago
I don't think it's about "rejection" but a practical thing. When starting a project you may need some 3rd party stuff (library, framework, etc) that doesn't support Python 3 (yet; for different reasons, sometimes the project is unmaintained, sometimes is a _huge_ project and Python 3 support is not ready, but I have yet to find a project that "rejects" Python 3). Because 2.x (2.6 to 2.7) is available, it's not a big deal and you just use Python 2. Thanks to 2.7 (that includes several features from Python 3), finally moving to Python 3 shouldn't be a pain for most people, once all your requirements support Python 3.
kzrdude 14y ago
Not easy to port pyGTK projects at all -- they didn't release until long after python 3's first release, and also combined the bump with a step to GTK3 and a different technology for the langauage bindings (gobject-introspections). Sure, all those three new things are better, but each of them add up to porting a complex app.
- takluyver 14y ago
  The best way is to get your application working with gobject-introspection and GTK3 on Python 2 first. Then it's very easy to port to Python 3.

taude 14y ago

Interesting. Maybe as the push to Python 3 gets more forced, more active-legacy code will be upgraded?

joemaller1 14y ago
Let's hope so, there's got to be a tipping point.

agung17 14y ago

thank you for the information, because I was new about the language of programmers in the world of IT http://www.obatkuatpria-pelangsing.com/ http://www.obatkuatpria-pelangsing.com/

smoyer 14y ago

I like Python, but keeping both 2 and 3 alive for so long has caused problems that make it hard to justify for serious projects. What will your boss decide when half his developers say that the two branch is right for a task and half say the three branch should be used? He'll pick another language. I'm not sure I'm willing to trust Ubuntu to decide this for me ... they also thought Unity was in my best interest, and foisted the Amazon store upon my desktop. Good luck Ubuntu ... I'm outta here.

ed_blackburn 14y ago
I've worked in environments where classic ASP, .NET 1.0, .NET 3.5 and 4.0 are all in production, some on the same server. I imagine there are similar tales regarding production environments for Java and Ruby etc. If you cannot run different versions simultaneously you have a problem. Thankfully you can.
andrewcooke 14y ago
ubuntu isn't deciding anything for you. both are available as packages. and the decision to introduce python 3 wasn't made by them anyway. for new projects where i control deployment i use python 3 (these days, the support is there - in fact in at least one case i am using a python 3 only lib). for maintenance or projects where the client has existing systems, i use whatever is most appropriate. i am a professional. i get the job done. what more is there to say? oh, yeah, running round throwing a hissy fit for internet points.
pcx66 14y ago
I think the way the Python community handled this change is really mature compared to several other communities who've been through such change. They've done great work in making sure one single codebase can support 2.6, 2.7 and 3.2/3, Django does this. Teams using Python to develop, in the present state, mostly base their decisions to chose py2 or py3 based on the maturity of the libraries (py3 ones) they are gonna use. Ubuntu devs are using good judgment here, they are first moving code they use for the OS from 2 to 3 and switch the default python package version. But py2 should be available to any package which specifies it as a dependency. This should be nearly invisible to a normal user. This also gives the much needed push for Py3 adoption.

agung17 14y ago

http://www.obatkuatpria-pelangsing.com/2013/04/vakum-pembesar-penis-handsome-up.html http://www.obatkuatpria-pelangsing.com/2013/04/vakum-pembesa... thank you for the information, because I was new about the language of programmers in the world of IT

rwmj 14y ago

Python 3.3 was added to Fedora in August 2012. Source: http://koji.fedoraproject.org/koji/packageinfo?packageID=9781 http://koji.fedoraproject.org/koji/packageinfo?packageID=978...

bluedino 14y ago
Fedora is more of a bleeding-edge (or at least developer-focused) distro - they also ship with Ruby 1.9 instead of 1.8.
- nXqd 14y ago
  +1 for Fedora :)
- alexchamberlain 14y ago
  Arch Linux all the way!
- kokey 14y ago
  Interesting, until last year I used to use Ubuntu when I wanted a bleeding edge and lightweight OS for, say, working with new hardware. How things change.
  - LukeShu 14y ago
    Fedora has always been bleeding edge. In my experience, to the point of being unstable, at least when a version is new (Installed Fedora 15 the day it came out, segfaults galore).
  - yogo 14y ago
    In its lifetime Ubuntu has never been bleeding edge nor lightweight compared to many other distros. I'm an Arch user all the way but I still take other distros for a test drive every so often and it amazes me the crap distros bundle together in packages when so many things could be made to be optional dependencies. I guess it all depends on your standard for lightweight :).
- 14y ago

stefantalpalaru 14y ago

There's always Linux Mint[1]. [1] http://www.linuxmint.com/about.php http://www.linuxmint.com/about.php

ubersoldat2k7 14y ago

I think it's good that they "force" a little for devs to start using Python3.

d0m 14y ago

Bha, I still believe that's a mistake. Breaking already existing and working tools for the sake of having python3. Thousands of scripts use "python" as default, instead of "python2". They will all break. The problem isn't when it's your own stuff. but mostly when you're using a automatically build system that use "python" somewhere. And then, that thing crashes because it's now expecting python2.. or that the 10 years old package would automatically be ported to python3. As far as I'm concerned, I would have preferred Python to be Python2.x, and a new code name for Python3, i.e. Cobra.

njharman 14y ago
If you want to live in the past, don't upgrade. If you want have your cake and eat it too, tough. Everyone else, will upgrade and rejoice that Ubuntu isn't 10 years behind like another CrimsonCap distro.
- lmickh 14y ago
  The CrimsonCap distro has supported side-by-side Python2 and Python3 for awhile now. There is already a process underway to get the larger components migrated to Python3. Sure the process isn't 100% complete, but it is hardly 10 years behind.
BCM43 14y ago
I'm guessing that Debian, if they have not already done it, will start searching packages for ^#/usr/bin/python$, and filing bug reports for packages that match. So that should not be as much of a problem. As for user-created scripts...
tshepang 14y ago
Nothing will break (in the sense you mention). Python 2 will remain /usr/bin/python while Python 3 is /usr/bin/python3.
- d0m 14y ago
  Ha, ok thank you. With archlinux, /usr/bin/python is now linking to /usr/bin/python3..

zurn 14y ago

Previous discussion: https://news.ycombinator.com/item?id=4486608 https://news.ycombinator.com/item?id=4486608 This was around Ubuntu 12.10, references Ubuntu wiki with nearly the same text back then.

levesque 14y ago

Been happily running Ubuntu 13.04 with Python 3.3 for a few weeks. Sure some packages will break, but it will initiate a real migration, and in the end Python3 will be the default Python. All in all, there's no way to make this transition without breaking stuff, it just needs to be done.

antihero 14y ago

Arch has been using Python 3 for quite a long while, now. However, any push that allows us to use 3.3 is a great thing. I've been reading the 3.3 docs and being like, neat feature! Then switching back to the 2.7 docs and realising I can't use it :(

eliben 14y ago
Yep, after the feature freeze between 3.1 and 3.2, 3.3 was a significant jump forward.

niggler 14y ago

When will perl6 become the standard perl?

chimeracoder 14y ago
Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked. Python 2 is not being developed actively, aside from security updates, so it is permanently frozen at 2.7, with the intent of removing support entirely eventually (though not for a while). It's not really a like comparison to compare the two.
- lmm 14y ago
  >Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked. It wasn't always that way, however much certain luminaries try to retcon. Perl6 was originally intended to be, well, the next version of perl; it was only after the community's rejection that the decision to continue perl5 happened. It's not beyond the realms of possibility that the same thing could happen to python (though I certainly hope not, and stories like this suggest we're reaching the tipping point).
  - chromatic 14y ago
    it was only after the community's rejection that the decision to continue perl5 happened. The lack of any usable Perl 6 implementation by the time of Perl 5.12 did more to promote the continuation of Perl 5 as its own project than any specific rejection of Perl 6. When the plan was for Perl 6 to replace Perl 5, the idea that Perl 5.12 would migrate to Parrot as a VM so that Perl 5 and Perl 6 code could run in the same process.
Flimm 14y ago
From what I've seen, the difference between Perl 5 and 6 is much greater than the difference between Python 2 and 3. For this reason, I have very little hope for Perl 6.

xtc 14y ago

Ubuntu also thinks Unity is a good idea.