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

Steve Holden steve at holdenweb.com
Wed Jan 10 21:40:32 CET 2007


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,
> 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?

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.

There could even be levels, so it was possible to configure your Python 
2.X to give specific advice about migration to particular future 
versions, without any change in the action of the interpreter in the 
absence of any indication that the user wanted migration warnings. That 
way we are guiding our forward-looking users towards the future without 
chastising others for adopting, or sticking with, older versions.

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