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

[anatoly techtonik]

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

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.