Armin’s a founding member of the pocoo team with projects like jinja2, werkzeug, sphinx and so.
Python 3 is the elephant in the room that nobody’s talking about. There’s a lot of python 2 code and porting is turning out to be harder than expected.
Some recent python developments:
Unladen swallow is “resting”. Development stopped. It was the number one hope to make python faster.
Python 3.2 got released.
Python’s packaging is being worked on a lot.
Pypy turns out to be quite fast nowadays. Really really fast.
What’s pypy? It is python written in python. Well, in “restricted python”, which can be translated to C automatically. It is 3.7 till 40 times faster than regular cpython!!! Things that will work? Django, flask, pyglet, twisted, sqlite, ctypes and so on.
A problem with pypy is that there’s only experimental support for the python C API. And C-level extensions will always be slow. And there is no reference counting, so you need (for instance) to close files yourself.
But, in summary, python 3 is where all the new language development is happening. What does python 3 mean?
Unicode cleanup. All text-like things are either unicode text or a binary blob.
The language is cleaned up a bit.
The cost… there’s some backwards incompatibility.
The good parts about python 3:
Unicode everywhere where it wasn’t possible before, like in exceptions. And the python source code is now also compiled into unicode, so unicode variables are now possible.
Big IO improvements regarding unicode.
A couple of handy new language constructs. For instance extended iterable
a, b, c* = some_tuple() with
c containing the rest of
The under-the-hood implementation was cleaned up a lot.
Various smaller things. Print is now a function. Obscure standard library modules were removed. No more classic classes. Absolute imports are standard now. Etc.
New python 2.6/2.7 features contain features that make it possible to write code that also works on python 3:
Print as a function.
New IO library.
Explicit byte literals to match python 3’s new string/unicode/bytestring handling.
Advanced string formatting. More advanced than the regular
string formatting. A new syntax that allows you to rearrange items in the
string which is often needed for translatable strings.
More things like support for fractions. Abstract base classes (basically “documented ducktyping…”). The multiprocessing package (which works much like the thread library, but fur subprocesses).
Going forward: currently you basically have to choose between beauty or speed.
The beauty of the code (python 3) or the raw performance of pypy.
Pypy itself will stay written in python 2, but the interpreter might someday support python 3.
Numeric libraries work great on python 3.
Pypy still lack proper C-api support.
Most people will write for python 2.7 without worrying about backwards compatibility. And with the intention of supporting pypy.
Python C api libraries will become less common. ctypes could help a lot and is often better. Pure python (with the help of pypy) is also fast.
We will see libraries that support both 2.7 and 3.x.
Python and the web, especially regarding python 3.
There’s a wsgi spec revision for python 3. And there’s some work done on porting implementations to python 3. Right now WSGI itself isn’t something people really want to change anymore: it just works.
Django and jinja could take advantage of pypy’s behaviour for their template compilation. He’s going to work on an implementation that allows django and jinja to use the same code.
How can we make python 3 work on the web?
Port libraries over to 3.x.
Issues with python 3 will only be resolved when people are actively porting and trip over those issues.
Higher level items like Django are easier to port over, the low-level libraries for network connections and so are the really hard nuts to knack.
It is not too hard to port if you can drop python 2.6 support. Good python 2.7 code can generally survive a 2-to-3 conversion just fine.
See http://bit.ly/python3-now for some pointers and tips.
We’re doing great regarding python web in general:
WSGI works out well in practice.
Pylons and BFG merged into pyramid, which means it is a nice introduction into the great ZOPE world.
There’s less and less framework specific code out there, there’s lots of reusable generic code.
New frameworks help figure out new paradigms.
Switching frameworks or using parts of different frameworks in the same code is generally no big problem. Python’s namespacing helps a lot here. You can use zope code in django just fine.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):