On 1/10/07, Steve Holden <steve@holdenweb.com> wrote:
Collin Winter wrote:
> On 1/10/07, Thomas Wouters <thomas@python.org> wrote:
>> On 1/10/07, Raymond Hettinger < raymond.hettinger@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@python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!