11 ms·
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 commun
by 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 agoTons of changes in 3 making it backwards incompatible + nearly 20 years of legacy Python libraries
- misnome 14y agoAll 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 agoIs 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 agoThat's the one I watch ... it's a lot greener today than it was 2 years ago.
- masklinn 14y agoIIRC 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 agoThere'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 agoGuido 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 agoWell, 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 agoDifference being that new versions of java, windows, c++ compilers work with the existing software.
- PommeDeTerre 14y agoThat 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 agoNot saying python 3 should have been compatible with 2. Just that this was not an apt comparison.
- cpeterso 14y agoIs there Java 6 code that is not forward-compatible with Java 7?
- FooBarWidget 14y agoAs 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 agoI'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 agoI 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 agoOne 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 agoPython 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 agoThat'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 agoI 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 agoIt 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 agoThe comparison may have made more sense with C and C++...
- masklinn 14y agoIt 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 agoHow 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 agoCan'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 agoFor a good start, has Perl 6 finally been released?
- sigzero 14y agoNot in a form that you would use for production, no.
- elbear 14y agoIf 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 agoAs 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 agoIt'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 agoThe 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 agoAround 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 agoI 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 agoNot 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 agoThe 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.