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

Collin Winter collinw at gmail.com
Fri Aug 24 18:46:29 CEST 2007


On 8/23/07, Guido van Rossum <guido at python.org> wrote:
> Yes, I think this would be way cool! I believe there are already a few
> fixers that print messages about things they know are wrong but don't
> know how to fix, those could also be integrated (although arguably
> you'd want those messages to be treated as more severe).

Adrian and I talked about this this morning, and he said he's going to
go ahead with an implementation. The original warning messages were a
good idea, but they tend to get lost when converting large projects.

Collin Winter


> On 8/23/07, Adrian Holovaty <adrian at holovaty.com> wrote:
> > 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
> > changes.
> >
> > Oh, and I'm happy to (attempt to) write this addition to the tool, as
> > long as the powers at be deem it worthwhile.
> >
> > Thoughts?
> >
> > Adrian
> >
> > --
> > Adrian Holovaty
> > holovaty.com | djangoproject.com
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/collinw%40gmail.com
>


More information about the Python-3000 mailing list