[Python-Dev] Can someone check my lib2to3 change for fix_imports?

[Collin Winter]

On Wed, Jul 2, 2008 at 1:09 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> Agreed. A lot of the pending bugs seem to be related to the version of
>> lib2to3 in the stdlib, rather than the stand-alone product. Neal
>> Norwitz and I have been working to turn parts of 2to3 into a more
>> general refactoring library; once that's done (or even preferably
>> before), lib2to3 should be removed from the stdlib. It's causing far
>> more trouble than it's worth.
>
> I disagree. I think it is quite useful that distutils is able to
> invoke it, and other people also asked for that feature on PyCon.

But distutils currently *doesn't* invoke it, AFAICT (unless that
support is implemented somewhere other than trunk/Lib/distutils/), and
no-one has stepped up to make that happen in the months since PyCon.
Moreover, as I told those people who asked for this at PyCon, 2to3 is
and will never be perfect, meaning that at best, distutils/2to3
integration would look like "python setup.py run2to3", where distutils
is just a long-hand way of running 2to3 over your code.

This strikes me as a waste of time.

> Why do you think the trouble wouldn't be caused if it wasn't
> a standard library package?

Problems with the current setup:
1) People are currently confused as to where they should be commit fixes.
2) Changes to the sandbox version have to be manually merged into the
stdlib version, which is more overhead than I think it's worth. In
addition, the stdlib version lags the sandbox version.
3) At least one bug report (issue3131) has mentioned problems with the
stdlib 2to3 exhibiting problems that the stand-alone version does not.
This is again extra overhead.
4) The test_imports test was commented out because of stdlib test
policy. I'd rather not have that policy imposed on 2to3.

Collin