[Python-Dev] [Python-3000] Warning for 2.6 and greater

Thomas Wouters thomas at python.org
Wed Jan 10 21:48:22 CET 2007


On 1/10/07, Steve Holden <steve at holdenweb.com> wrote:
>
> Collin Winter wrote:
> > On 1/10/07, Thomas Wouters <thomas at python.org> wrote:
> >> On 1/10/07, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> >>> It is my strong preference that we not go down this path.
> >>> Instead, the 2.6 vs 3.0 difference analysis should go in an
> >>> external lint utility.
> >>>
> >>> The Py2.x series may live-on for some time and should do so
> >>> as if Py3.x did not exist.  Burdening the 2.x code with loads
> >>> of warnings will only clutter the source code and make maintenance
> >>> more difficult.  There may also be some performance impact.
> >>>
> >>> We should resolve that Py2.6 remain as clean as possible
> >>> and that Py3.0 be kept in its own world.  Forging a new
> >>> blade does not have to entail dulling the trusty old blade.
> >> The idea is that we only generate the warnings optionally, only for
> things
> >> that can be written in a manner compatible with prevalent Python
> versions,
> >> and in the most efficient manner we can manage, *except* for the few
> things
> >> that are already considered (by many) criminal to use: input(),
> backtics,
> >> mixed tabs and spaces. In other words, for any code written even
> remotely
> >> sane in the last five years, no extra warnings will be generated.
> >
> > I'd rather see this effort invested in a tool like Guido's 2to3,


They serve a different purpose, and it isn't taking any time away from me
(or Anthony, I can confidently guess) working on 2to3.

> rather than in sprinkling warnings all through the 2.x codebase (even
> > if they are wrapped in #ifdef's). I don't imagine people developing
> > day-to-day in a 2.x environment are going to be so terribly interested
> > in "is this 3.x compliant?" that downloading a separate tool would be
> > an undue burden.
> >
> I'm all for helping people to prepare for 3.0, since I don't want to see
> it languish in Perl 6 country. At the same time I agree with Raymond
> that migration to 3.0 can't be allowed to place obstacles in the way of
> 2.X users. They shouldn't be penalised for using 2.X, particularly if
> they are new to the language, otherwise we will run the risk of
> adversely affecting the Python adoption rate - which I hope no reader of
> this list wants.
>
> So, why not a new warning category: MigrationWarning?


I believe Anthony suggested Py3KDeprecationWarning or such. I don't think
the name really matters.

This type of warning should appear only when the user specifically
> configures their Python installation to provide them, thereby allowing
> existing production code to continue working without users needing to
> switch warnings off.


Sorry, that doesn't work -- most programmers don't build their own Python,
and it's way too much to expect all distributions to provide two versions of
the same Python. Let's not over-engineer this. We'll add the warning flag
the way Anthony suggested, and measure the speed impact. If the speed impact
is too high, we should just forget about it. This isn't a spaceship, this is
just a little deprecation warning for people who want to see it -- people
who wonder whether python3.0 will really be all that different, whether
their code will need extensive modification or not, but don't want to
download a conversion tool and/or a python3.0 installation just to figure
that out.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070110/50d98120/attachment-0001.htm 


More information about the Python-Dev mailing list