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

Steve Holden steve at holdenweb.com
Wed Jan 10 23:39:54 CET 2007


Thomas Wouters wrote:
> 
> 
> On 1/10/07, *Steve Holden* <steve at holdenweb.com 
> <mailto:steve at holdenweb.com>> wrote:
> 
>     Collin Winter wrote:
>      > On 1/10/07, Thomas Wouters <thomas at python.org
>     <mailto:thomas at python.org>> wrote:
>      >> On 1/10/07, Raymond Hettinger < raymond.hettinger at verizon.net
>     <mailto: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,
> 
The above appears to be a quoting error, attributing comments to me that 
were actually made by Collin Winter.
> 
> 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.
> 
I quite agree. I was really disagreeing with the proposal that the new 
warning be a subclass of DeprecationWarning, since that implies that 
warnings will appear without being requested - that would, IMHO, be a 
sad approach to migration. I'd like users who decide to remain with the 
2.x series not to suffer at all as a result of that decision (except for 
missing out on a major language development, of course).

>     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.
> 
Two versions aren't required, and that's not what I was proposing. There 
should be a command-line an option to switch these warnings *on*, rather 
than having to take the usual action of turning DeprecationWarning 
*off*. In other words, only intrude on the lives of those who 
consciously seek advice on migration.

Quite happy to drop the idea if the impact on execution speed is too 
great, but I anticipate most of the warnings would occur during parsing 
and code generation, and having them off by default ought to minimise 
the impact.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Blog of Note:          http://holdenweb.blogspot.com



More information about the Python-Dev mailing list