5 ms·

Writing Python 2.x forward compatible to Python 3 code

94 points by bretpiatt 16y ago

viraptor 16y ago
> 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.
- mariana 16y ago
  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.
  - viraptor 16y ago
    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.
    - ubernostrum 16y ago
      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...
      - viraptor 16y ago
        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.
- zcid 16y ago
  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.
  - cookiecaper 16y ago
    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.
- cdavid 16y ago
  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.
djacobs 16y ago
As someone who's learning both right now and not sure which to use, this is invaluable.
- prog 16y ago
  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.
  - dgallagher 16y ago
    ...which raises the question: Does anyone know when Django plans to migrate to Python 3.x? Django 2.0 perhaps, whenever that may be?
    - koenigdavidmj 16y ago
      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.
      - deleted 16y ago
        [deleted]
      - dlib 16y ago
        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?
        koenigdavidmj 16y ago
        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.
        16y ago
ylem 16y ago
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...
- mgedmin 16y ago
  details?
davidhollander 16y ago
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/ 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 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/ https://bitbucket.org/amentajo/lib3to2/

94 points by bretpiatt 16y ago

> 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.

mariana 16y ago
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.
- viraptor 16y ago
  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.
  - ubernostrum 16y ago
    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...
    - viraptor 16y ago
      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.
zcid 16y ago
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.
- cookiecaper 16y ago
  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.
cdavid 16y ago
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.

djacobs 16y ago

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

prog 16y ago
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.
- dgallagher 16y ago
  ...which raises the question: Does anyone know when Django plans to migrate to Python 3.x? Django 2.0 perhaps, whenever that may be?
  - koenigdavidmj 16y ago
    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.
    - deleted 16y ago
      [deleted]
    - dlib 16y ago
      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?
      - koenigdavidmj 16y ago
        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.
      - 16y ago

ylem 16y ago

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...

mgedmin 16y ago
details?

davidhollander 16y ago

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/ 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 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/ https://bitbucket.org/amentajo/lib3to2/