[Python-3000] Should 2to3 point out *possible*, but not definite changes?

Adrian Holovaty adrian at holovaty.com
Fri Aug 24 04:50:16 CEST 2007

As part of the Python 3000 sprint (at Google's Chicago office), I've
been working on the documentation for 2to3. I'm publishing updates at
http://red-bean.com/~adrian/2to3.rst and will submit this as a
documentation patch when it's completed. (I didn't get as much done
today as I would have liked, but I'll be back at it Friday.)

In my research of the 2to3 utility, I've been thinking about whether
it should be expanded to include the equivalent of "warnings." I know
one of its design goals has been to be "dumb but correct," but I
propose that including optional warnings would be a bit
smarter/helpful, without risking the tool's correctness.

Specifically, I propose:

*  2to3 gains either an "--include-warnings" option or an
"--exclude-warnings" option, depending on which behavior is decided to
be default.

* If this option is set, the utility would search for an *additional*
set of fixes -- fixes that *might* need to be made to the code but
cannot be determined with certainty. An example of this is noted in
the "Limitations" section of the 2to3 README:

      a = apply
      a(f, *args)

(2to3 cannot handle this because it cannot detect reassignment.)

Under my proposal, the utility would notice that "apply" is a builtin
whose behavior is changing, and that this is a situation in which the
correct 2to3 porting is ambiguous. The utility would designate this in
the output with a Python comment on the previous line:

      # 2to3note: The semantics of apply() have changed.
      a = apply
      a(f, *args)

Each comment would have a common prefix such as "2to3note" for easy grepping.

Given the enormity of the Python 3000 syntax change, I think that the
2to3 utility should provide as much guidance as possible. What it does
currently is extremely cool (I daresay miraculous), but I think we can
get closer to 100% coverage if we take into account the ambiguous

Oh, and I'm happy to (attempt to) write this addition to the tool, as
long as the powers at be deem it worthwhile.



Adrian Holovaty
holovaty.com | djangoproject.com

More information about the Python-3000 mailing list