Great news. The two biggest hurdles for Python3 adoption were/are Numpy/Scipy and Django. Now that Numpy/Scipy both officially support Python 3.x[1] and with Django coming soon, I expect a lot of people will make the transition to Python3.x for new projects.
It may sound strange, but we're the other way around. With Python 3 being the only future of Python, the inability of something like Django to support Python 3 is, for us, a hurdle to adopting Django, not Python 3.
This has retarded any progress of mine toward learning Python. Every so often the urge strikes me, and then I remember that I want to learn Python 3, and then I remember that means no Django, and I tend to go and learn something more fun and less practical...
By any means, if you feel the urge, you really should help yourself and scratch that itch.
I understand that for someone new to python (hence lacking the knowledge to get what's different between 2 and 3) you might feel uneasy about it, but really you should not.
Just learn py2.7 (+ django if that's you want) now, and bulletproof your code by using u"", b"", .encode and .decode at the edge when needed, also 123L in your code, together with from __future__ import division, print_function, and whatnot. The remainder is mostly syntax (like except) or namespace (like http.server) changes and will get caught and thus easy to fix when you try to run in py3 (contrary to if you don't use u""/b"" as values can "move" through code and blow up in a completely unrelated area). I might be forgetting something, but that's the gist of it.
As for learning, really you will have zero trouble acclimating yourself to any breaking change py3 introduces. The trouble only lies in existing, 'legacy' code, not for the one you write from scratch straight in py2.7, and especially if you aim for compatibility with the provided forward-compatibility features of python.
Great post. A point I want to emphasize is that learning py2.7 is learning Python 3, if you are careful to pay attention to the recommended/pythonic way of doing things.
For the most part Python 3 removes syntax and functionality that was long-since depreciated or at least strongly advised against.
Perhaps, but the lack of bytestrings seems to be what bites everyone. It's the only "deep" change and it affects anyone who wants to slice raw bytes (which includes most web frameworks).
Unfortunately all the hooplah about Python 2/3 porting has created an image, reflected in your posting, which is simply not true. To a large extent Python 3 is just a superset of the functionality of Python 2.x, adding such features as keyword-only arguments and exception chaining. This is typical for Python: each new release typically includes a handful of new community-vetted syntax features. What's unique about Python 3.0 is that this one, exceptional time they allowed themselves to go back and eliminate deprecated syntax and functionality, and to tweak a few aspects of the language (namely Unicode strings) in subtle, but fundamental ways.
It's been a long, drawn-out process in part because everyone uses Unicode strings (and if you're not, you should be). Python 2.x let you be fairly lax about unicode vs. legacy/byte strings. Python 3 forces you to clean up your act and be explicit. Other than that the two languages are -basically- the same. This isn't like C vs. C++ (which share an unhealthy fetish for curly braces but are quite different under the surface), but rather more like K&R C vs ANSI C, or C++03 vs C++0x.
In other words if you're waiting for Django/SQLAlchemy/whatever to transition, don't bother. Learn Python 2.7 today, use it, love it, and transition to Python 3 only when all your dependencies have made the switch. You'll then have to change a few minor things like "raise Exception, reason" to "raise Exception(reason)", but I'm sure you'll adapt just fine.
A couple years ago I decided to learn Python. I took a quick look, saw Python 3 was the "latest", and started working on my app, using http://docs.python.org/py3k/ as my guide.
It wasn't until a month later when I went to deploy that I discovered Python 3 wasn't what everyone was using. It was a small app, so it only took me a a day to port it to 2.6.
My point is go ahead and learn Python 3. The hurdles of back-porting are pretty minor when you don't have any version specific habits.
It may sound the same, but I had that same feeling towards Python. I eventually dipped my toe into Python 3, but my main desire was to use Django for a work project and naturally we ditched it for ASP.NET (a decision I don't regret as ASP.NET is a great framework).
matplotlib is the defacto standard for plotting data in Python and could definitely be considered a hurdle. I haven't followed to closely but it looks like support for 3.x is coming along nicely[1].
GUI toolkits like wxPython and PyQT/PySide supporting Python3 will also be important.
I'm not sure how outdated this is, but there's a list of most wanted Py3k packages available here: http://www.python.org/3kpoll
PIL is also somewhat labyrinthine, so porting may be particularly slow. I've been using ctypes to load GraphicsMagick (JAI on Jython), which is easier to start and less of a challenge where PyPy is concerned:
> pixels: A list of arrays (array.array). Each array in the list is a line in the image. Each array is the actual image data for that line in the image.
This seems like a silly thing to do. It would make for much more readable code to use numpy arrays. But regardless, the pixel data should be one single array of data.
It looks to me like the guy working on this hasn’t spent tremendously much time thinking about good image APIs. Is there any document that describes the design goals and process?
array.array is fine, I guess, but using a list of array.array objects is inelegant and inflexible. It’s much better to put all your image data in one big array, keep track of the various stride lengths to go down rows or across pixels, and then implement proper multi-dimensional indexing.
I suppose it doesn’t really matter. This library is also missing all the other flexibility you’d want in a general imaging toolkit – e.g. the assumption of 8 bit/channel RGB is baked into everything, with no notion of color space or gamma encoding (and the JPEG decoder doesn’t seem to have any mention of color spaces, meaning that many JPEG images will be wrongly interpreted). It’s not usable for any but the most basic image processing tasks.
The JPEG decoder might make an okay benchmark for pypy performance, though it’s a straight port from C++, so it’s probably not the style of python code that pypy is designed to be fast on.
I believe Jonas is approaching it from his position as a web developer and Django author who's spent a LOT of time dealing with requests from people who've had trouble with PIL and generally only use 8-bit RGB.
I'd be reluctant to condemn a project which is a few days old. Having spent time wrestling with optimizing the horror which is the PIL code, I'd definitely suggest that having a pure Python implementation will make it much easier for people to experiment with API and performance improvements.
1. http://scipy.github.com/faq.html#do-numpy-and-scipy-support-...