[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