[Python-Dev] 2to3 porting HOWTO: setup.py question

[Oscar Benjamin]

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.build_py import build_py_2to3 as build_py
> > > > except ImportError:  # Python 2
> > > >   from distutils.command.build_py import build_py
> > > >
> > > > instead of explicit check like:
> > > > import sys
> > > > if sys.version_info[0] >= 3:
> > > >     from distutils.command.build_py import build_py_2to3 as build_py
> > >
> > > 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.version_info 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 build_py_2to3 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 build_py_2to3 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>