1. http://scipy.github.com/faq.html#do-numpy-and-scipy-support-...
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.
For the most part Python 3 removes syntax and functionality that was long-since depreciated or at least strongly advised against.
b'foo'
The list you've given looks like a good start - is there a definitive list you'd recommend anywhere?
[0] http://docs.python.org/release/3.2.1/whatsnew/3.0.html
[1] http://docs.python.org/release/3.2.1/whatsnew/3.1.html
[2] http://docs.python.org/release/3.2.1/whatsnew/3.2.html
[3] http://www.ibm.com/developerworks/linux/library/l-python3-1/
[4] http://www.ibm.com/developerworks/linux/library/l-python3-2/
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.
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.
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
https://github.com/acdha/NativeImaging
There's also a very new project started here at PyCon to build a completely native Python imaging library:
https://github.com/ojii/pymaging
Obviously it's nowhere near as fast, although it'll be interesting to see how PyPy performs
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?
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'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.