[Python-Dev] 2to3 porting HOWTO: setup.py question (original) (raw)

Oscar Benjamin oscar.j.benjamin at gmail.com
Sun Jul 22 23:21:04 CEST 2012

On 22 July 2012 20:57, R. David Murray <rdmurray at bitdance.com> wrote:

Benjamin sent me this message separately(*) privately and I responded privately. Here is my response.

(*) or his mailer did

I think I accidentally replied from my work email address (which is not subscribed to python-dev) and so the second copy I sent to python-dev wasn't posted.

On Sun, 22 Jul 2012 20:22:50 +0100, Oscar Benjamin <oscar.benjamin at bristol.ac.uk> wrote: > On 22 July 2012 14:08, R. David Murray <rdmurray at bitdance.com> wrote: > > > On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik <_ _techtonik at gmail.com> > > wrote: > > > http://docs.python.org/py3k/howto/pyporting.html#during-installation > > > > > > What's the point in making implicit Python 3 check here: > > > try: # Python 3 > > > from distutils.command.buildpy import buildpy2to3 as buildpy > > > except ImportError: # Python 2 > > > from distutils.command.buildpy import buildpy > > > > > > instead of explicit check like: > > > import sys > > > if sys.versioninfo[0] >= 3: > > > from distutils.command.buildpy import buildpy2to3 as buildpy > > > > It's called testing for the thing that actually matters, rather than > > testing a constant with a much broader meaning. Yes, in this case the > > results are the same, but IMO it is better programming practice to test > > the thing that actually matters when you can. > > > I recently changed a setup.py from try/ImportError to an explicit > sys.versioninfo check. I'm not totally sure how to reproduce this but I > had a problem where I was installing into a 2.x virtualenv and it was > running 2to3 during install and subsequently failing to import the 3.x code > (the problem didn't occur when using the same python that generated the > virtualenv). > > I may be wrong but I imagined that sometimes buildpy2to3 is importable on > 2.x, perhaps for cross-building or something. In any case 'testing the > thing that matters' means testing what version of Python you are about to > install into not whether the python version supports running 2to3. I'm not familiar with distutils, really, so you could be right about what it is important to test. I was commenting based on the code snippet presented, which just deciding which "build" object to use. If buildpy2to3 can be imported by python2 and subsequently screws up the build, then yes the logic is incorrect. But I have to defer to the packaging people on that. (I wish I had time to help with packaging because it is important, but it doesn't seem like a sensible place for me personally to spend my currently available time.)

I'm not currently able to reproduce the problem on this machine. I think I was using pip/easy_install to install distribution X from PyPI that depended on distribution Y also on PyPI into an isolated 2.x virtualenv and found that distribution Y was converted with 2to3 when it was automatically installed. It could be a bug but I'm not confident enough with virtualenv to say that it wasn't just me messing things up somehow.

Either way I still think that in this particular case a version check is the most explicit and appropriate thing to do. The author of a distribution that is distributed as Python 2.x code and installed on Python 3.x using 2to3 knows precisely when they want 2to3 to run and when they don't so why not make that explicit?

As an aside, I find the check slightly easier to read if it is written like:

if sys.version_info >= (3, 0): from distutils.build_py import build_py_2to3 as build_py

Cheers, Oscar. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120722/37eb4461/attachment-0001.html>

More information about the Python-Dev mailing list