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?
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.
https://pypi.python.org/pypi/Pillow/2.0.0
> NumPy
We're at almost three years now that people have been wrongly complaining about NumPy not being on Python 3. When do you think it will end?
http://www.mail-archive.com/numpy-discussion@scipy.org/msg26...
> PyPy
It's getting close.
http://morepypy.blogspot.com/2013/03/py3k-status-update-10.h...
Pillow works on py3 as others have already mentioned.
For current status see https://gist.github.com/untitaker/5321447 (Werkzeug is the most significant Flask dependency)
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.
In my experience, Python developers put much more emphasis on creating systems that are correct, secure, robust and reliable. Part of this involves thinking through any changes thoroughly, and being somewhat conservative in the adoption of new technologies and techniques.
The Ruby community, on the other hand, generally places much less emphasis on such factors. They're often much more willing to use newer software, even if it means the stability, correctness and security of the software systems they're building is decreased.
So it doesn't surprise me at all that Ruby developers would rush to a new version, while Python developers take a slower approach involving more thought and care.
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.
(The plan for this was originally announced[2] in 2011.)
1. 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/
If Rails didn't support Ruby 1.9, I'd imagine the migration would have been slower.
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.
Most of Python's features are carefully crafted to not cause compatibility issues. 3.x is the major exception in many, many years.
IIRC most of the big packages have finally moved over so it'll just become less of an issue over time.
Edit: I found one here https://python3wos.appspot.com/ and another one here http://py3ksupport.appspot.com/
Looking forward to NLTK 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.
[1]: http://blog.briancurtin.com/posts/the-year-of-the-snake.html
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.
...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?
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).
At least Python 3 exists, and is usable for production-grade systems. Its adoption may not have been as quick as anticipated, but at least it does exist, and it is usable.
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.
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.
Sure, all those three new things are better, but each of them add up to porting a complex app.
Python 3 isn't just a little bit incompatible in a few places, it has widespread incompatibilities and is therefore effectively a different language.
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.
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.