-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 10, 2007, at 2:42 PM, Thomas Wouters wrote:

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. By Guido's plan, 3.0 will arrive well before 2.6, and the migration step is not as large as many fear it to be. Having Python 2.6 optionally warn for 3.0-compatibility is a lot easier for the average developer than having a separate tool or a separately compiled Python.

I tend to agree with Raymond that Python 2.x will live longer than any of us think it might, or would hope for. I think it's even possible that there will be enough commercial impetus to keep 2.x alive with security updates (though with no new features) for a long while after 2.9 is released. I also think that the migration path may be more difficult than we think, especially with the unicode/str changes. Maybe it will be smooth and easy, but we don't know yet. (Heck, my company probably won't even upgrade from Python 2.4 to Python 2.5 any time soon.) Having said that, I don't have too much of a problem with the general guidelines Thomas outlines above. Just be really careful about what you criminalize in 2.6 because each will cause some current users pain. I think the other thing we've learned is that we may not know how much pain we cause until after Python 2.6.0 is released and ultra- conservative users start to upgrade. I can probably get on board with the three specific cases you mention above, because /my/ code is probably safe (although I wouldn't be surprised if some 10+ y.o. code still has a few lurking backticks), but I might balk if that slope gets any more slippery. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRaVFinEjvBPtnXfVAQJKYgQAg3RjH5OPF9TkdtWHqp9ylwnsRaBwuUdI MGSD5ukkddl7XuluHMxVDIduxxTrQos9bCacLPtK5YejhxKnXU0V8jfDYyXv1pDB j+DHJZ6cHQFTWfA7M48DMNPGoBSv0RyOSnrE9fMVrQ5D1dKO4sBIczzAMZ83y405 Zg3aDGE2voI= =wo27 -----END PGP SIGNATURE-----

Collin Winter wrote:

On 1/10/07, Thomas Wouters 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

On 1/10/07, Raymond Hettinger wrote: 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

Thomas Wouters wrote:

On 1/10/07, *Steve Holden* mailto:steve@holdenweb.com> wrote:

Collin Winter wrote: > On 1/10/07, Thomas Wouters mailto:thomas@python.org> wrote: >> On 1/10/07, Raymond Hettinger < raymond.hettinger@verizon.net mailto: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,

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

Thomas Wouters wrote: [...]

Ok, so, you're actually agreeing, except for the DeprecationWarning subclassing. There was never an intent to display these py3k deprecation warnings without an explicit flag (at least, not in this thread.) Hopefully that puts some people at ease.

If the action is as stated above you could make it a subclass of DeprecationWarning as far as I am concerned. 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

[Anthony Baxter]

I've had a number of people say that this is something they would really, really like to see - the idea is both to let people migrate more easily, and provide reassurance that it won't be that bad to migrate!

If Py3.0 is going to come out before Py2.6, can we table the discussion until then? We may find that a) migration was easier than we thought, b) that stand-alone migration tools are sufficient, or c) by the time Py2.6 comes-out, no one cares about having 2.x vs 3.x warnings. OTOH, if people do care, then we'll have a strong case for loading these warnings into Py2.6 before it gets close to being final. Also, I'm wondering if the desire for 2.6 warnings is based on the notion that it will be possible to get large tools to work under both Py2.x and Py3.x. With all the module renaming/packaging, old-style classes disappearing, encoded text objects, real division and whatnot; that notion may be a pipe-dream. As far as "reassurance that it won't be that bad to migrate", screens full of warnings may be less than reassuring. Raymond

sorry this is actually more an answer to Raymond's email but I accendidentally delete it some I'm replying there. On Wednesday 10 January à 20:42, Thomas Wouters wrote:

On 1/10/07, Raymond Hettinger wrote:

<"Anthony Baxter"> > Comments? What else should get warnings?

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.

Just notice that pylint is already warning for some py3k deprecation such as input(), <> and so on. It would be pretty easy to add warnings for the missing stuff provided a complete list of changes. Even better, pylint sorts its messages between various categories, and it would be as easy to get a py3k migration category so users can launch pylint to get only migration related messages (or filter them out as well). IMO that could be acheive in a couple of hours without anymore work involved. -- Sylvain Thénault LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science

On Thursday 11 January 2007 05:13, Raymond Hettinger 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.

I don't see how an external utility can possibly catch everything that's going to break - it's going to be much much easier to catch things like use of has_key and the like from inside the interpreter. Additionally, catching things like C code extensions using a slot or a method or a function that's going away is just not going to be possible otherwise.

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.

If it's a single check of a C int, the performance impact will be minimal. I agree that 2.x will live for a long time - but unless we provide the best possible upgrade path, we will be stuck maintaining both 2.x and 3.x for ever. Additionally, without a 2.x<->3.x upgrade path 3.x is essentially a new language, having to build a new userbase from scratch. Worse yet, 2.x will suffer as people have the perception "Python 2? That's a dead/abandoned language"

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.

I completely disagree here. We cannot simply ignore 3.0 in the 2.x series. We need to provide (as much as possible) an upgrade path for people who write and use code in the language. Anthony -- Anthony Baxter It's never too late to have a happy childhood.