On Mon, Jul 23, 2012 at 12:21 AM, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: >> On Sun, 22 Jul 2012 20:22:50 +0100, Oscar Benjamin >> <oscar.benja...@bristol.ac.uk> wrote: >> > On 22 July 2012 14:08, R. David Murray <rdmur...@bitdance.com> wrote: >> > >> > > On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik >> > > <techto...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
