This is a rough transcript, with links, of a 3-minute lightning talk I gave at LCA. It’s obviously not a complete argument; just a 180-second pitch for why the drama about Py3k is all smoke and no fire.
I’m excited about porting my code to Python 3, and you should be, too.
I’m sure all the Python users here are aware of the recent release of Python 3.0. Python 3.0 is the first Python release in something like a decade that is fundamentally incompatible with the previous release. There’s been a lot doom & gloom & naysaying about this. Some have suggested that Python 3 marks the moment where Python jumped the shark.
That’s not true, and I’m going to tell you why.
So, I’m one of the maintainers of Django. Django’s about 75 kLOC, and it won’t run under Python 3. Nor will anything I’ve written in Python to date. In my near future I see quite a bit of time porting code to Python 3 — as does every maintainer of every other Python program out there.
Now this sounds very scary. It sounds like I’m saying that every single one of the millions of lines of Python out there is going to have to be ported to a new language. You can see why this would cause a lot of angst: it seems like an impossible task.
But I’m still incredibly excited about porting to Python 3, and I’m going to give you three reasons why you should be excited, too.
First, there’s no hurry.
Python 3.0 is out today, but I don’t think anyone really expects you to switch to it immediately. Support for the Python 2 series will continue in parallel for quite some time. Many features of Python 3 will be backported into the Python 2 series, so you can make the move in baby steps.
A five-year timeline for moving to Python 3 is entirely reasonable. Python 2 isn’t going anywhere.
Second, it’s not going to be that hard.
Python 3 ships with a tool, 2to3 which will automate a great deal of the gruntwork. A great deal of code can be automatically upgraded to Python 3. Where tools won’t work, there are human resources. There’s a dedicated python-porting mailing list for help with porting code to Python 3.
If you’ve got good test coverage, porting these final bits should be easy, though not exactly fun. Run tests, fix failures, rinse, and repeat. If you don’t have good test coverage, I don’t have a lot of sympathy for you.
Finally, it’ll be worth your effort.
Python 3 has a huge set of improvements I can’t possibly enumerate. But more importantly, Python 3 is simply a better foundation from which to build the language forward. Improvements past 3.0 will come quicker and be more profound.
We all refactor code to take advantage of better APIs, or to build on improved frameworks, or to make an investment in future technology. Refactoring is part of the lifecycle of a healthy project. Moving to Python 3 is one of these refactorings. And we all know that while refactoring can be painful, the grass is indeed greener on the other side of this particular fence.
So, relax and don’t worry. Trust in Guido and your faith shall be rewarded!
Comments:
I know a lot of my concerns are about the porting timetables for extension modules. Pygame is a good example, sure they have spoken about a 3.0 port, I just haven't seen anyone volunteer the time to fix all the C API breakages. Now if only 2to3 could handle C code too ..... :-)
My hope is that the move to Python 3 will galvanize developers to take a more serious look at ctypes instead of extension modules. Modules written with ctypes are far easier to distribute, have a stable API, are portable across Python versions, and are generally easier to develop and maintain. There's even compatibility wrappers for other implementations done (PyPy) or in the works (Jython). My experience has been that the performance loss is negligible, though I'm not sure what the hit would be for something like pygame.
Another good option for extension modules is Cython. It's now possible to do it with entirely pure python and have the import/compilation phase be totally transparent, which is obviously nice :)
Has anyone seen if SWIG is interested in making a ctypes backend? That would also probably help a good bit. My only major problem with ctypes is the overhead still about 3x a normal extension module call. From what I can tell this is a general issue with libffi, because I got around the same numbers using CFFI (also libffi-based) in Lisp.
This is a derail, but ctypes doesn't have access to compile-time C headers and type definitions, so it isn't exactly equivalent to extension modules (my use case was portably wrapping some glibc api). Cython should do the trick though.
http://docs.python.org/dev/...
this link is broken. thanks
Leave a comment: