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

anatoly techtonik techtonik at gmail.com
Mon Jul 23 23:50:52 CEST 2012

On Mon, Jul 23, 2012 at 12:21 AM, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:

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/easyinstall 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.versioninfo >= (3, 0): from distutils.buildpy import buildpy2to3 as buildpy

Yes. This looks better. If we reached consensus, I wonder how hard is it to find somebody who have the rights and able to fix the documentation: http://docs.python.org/py3k/howto/pyporting.html#during-installation

anatoly t.

More information about the Python-Dev mailing list