[Python-Dev] Can someone check my lib2to3 change for fix_imports? (original) (raw)

Collin Winter collinw at gmail.com
Wed Jul 2 22:40:42 CEST 2008

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

More information about the Python-Dev mailing list