Writing Python 2.x forward compatible to Python 3 code | Hacker News Reader

Writing Python 2.x forward compatible to Python 3 code

lucumr.pocoo.org

94 pointsbretpiatt22 comments

For web development in Py3k the big holdback has been PEP3333, but it recently stabilized this month which is great news! http://www.python.org/dev/peps/pep-3333/

Also be aware of the following:

There is currently no memcached library for Py3k. https://github.com/lericson/pylibmc/issues#issue/21

[edit: If you use the uWSGI appserver with nginx or cherokee to deploy, I believe it will have cacheing for Py3k in its .97 release next month]

One of the problems is python.org has been emphasizing a Python2to3 without a Python3to2 converter. The ideal situation would be library, framework and module developers write in Python 3 and release a compatibility Python2 version via an automated converter, rather than the other way around. Otherwise they will be forced to do primary development in Python2 and not have the resources to maintain a separate Py3 branch.

Link to Python3to2 repository: https://bitbucket.org/amentajo/lib3to2/

As someone who's learning both right now and not sure which to use, this is invaluable.

I would love to use 3.x but went with 2.7.x as I need Django, and cx_Oracle. Django is 2.x only, I haven't really checked cx_Oracle.

...which raises the question: Does anyone know when Django plans to migrate to Python 3.x? Django 2.0 perhaps, whenever that may be?

They currently are compatible back to 2.4. They want to drop one Python release per Django release (1.3 will support 2.5 and up, 1.4 will support 2.6 and up). 2.6 is the cutoff when syntax will work everywhere.

How are they dealing with Google AppEngine's support for 2.5 when Django reaches 1.4? Or is AppEngine also expected to upgrade to 2.6 (or higher) anytime soon?

They still maintain the old versions too. Last security update featured new point releases of 1.1, 1.2, and 1.3 beta. So you can just use the old version until Google get their act together.

Technically, Django doesn't run on GAE. All the options to get it running on GAE involve quite a bit of hacking of Django. So there really isn't any support to maintain.

Not quite. 1.3 won't be dropping support for Python 2.4, because we can't quite do that yet.

Does anyone know when Django plans to migrate to Python 3.x?

I do.

(what, people don't like a joke? I happen to know the rough timeline; when it becomes a specific timeline sometime in the very near future -- probably around the time we release 1.3 -- y'all will know about it too)

cx_Oracle is py3k compatible. I'm really confident we'll have Django running on py3k by the end of the summer, hopefully I'll have something exciting to announce about this coming up, but if not I'll just dedicate my summer to it.

> For new projects, start with Python 2.6 or 2.7

Unless you want your project used on debian stable, that is... In which case your exception handlers will be simply not compatible between versions.

The next release of Debian stable will have Python 2.6 as default and it is expected for the first weekend of February, so it is safe to start with Python 2.6 right now.

True. However keep in mind who uses debian stable... people who won't jump on squeeze the moment it gets stable. It will still take months before the situation really changes. But yeah - I agree that 2.6 is pretty much safe for new stuff.

People who use Debian stable also aren't going to use your new library anyway. They're not running stable because they want to install a bunch of recent stuff, after all...

Why wouldn't they? I had to choose which version to target when writing some software lately. The production was debian stable yet I wanted to release the project for others. In the end I have to keep 2 branches - one for 2.X and another for 3.X - it was a trivial piece of code, so it's not a big problem, but I can imagine how silly it must be for bigger projects.

I believe the major issue right now is Red Hat. I can't find the emails detailing the issue right now, but apparently for applications like Django, they are worried about long term support in RHES for python 2.4 or 2.5 for at least another year or two.

So for python applications that are designed for server deployment, you need to look carefully at what versions your commercial linux users are running. While smaller deployments are important too, the enterprise customers are the ones that will say when 3.x is relevant or not.

This is where I think the server distributions get a little bit ridiculous. It is really silly that everyone on Red Hat is still stuck on 2.4. I understand that keeping a certain set of software at the same version for a while can be useful for system administrators, but really it's time 2.4 bid us adieu.

I'd really like to see a somewhat tighter release cycle from Red Hat, or for people to stop caring about supporting Red Hat after a while. The whole ecosystem shouldn't be trapped because Red Hat's customers, many of whom still have FORTRAN and COBOL programs performing important business functions, don't like to upgrade.

The rationale for supporting python < 2.6 goes much further than debian stable. Most "enterprise" linux distributions (e. g. RHEL) still require python 2.4.

It is incredibly difficult to install your own python once you need some extra libraries with C dependencies. For example, if you build your own python, say 2.6 on RHEL, but you need to use pyqt, you are in for a fun ride if you don't have admin privileges on your machine.

Have any of you looked at the changes in how super works from python 2.5 to 2.6 and how it changes for 3.0? This has bitten me for a library I was using with Django...

details?

Reply on news.ycombinator.com