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

[Raymond Hettinger]

<"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.


Raymond



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000-checkins] r53335 - in python/branches/p3yk: Doc/Makefile.deps Doc/lib/lib.tex Doc/lib/libsets.tex Doc/lib/libstdtypes.tex Lib/msilib/__init__.py Lib/sets.py Lib/test/test

[Brett Cannon]

On 1/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Should we bother with deprecating 'sets' in the 2.x series?
>
> I'd say so, yes.
>

OK, I work on deprecating the sets module in 2.6 .

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Thomas Wouters]

On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> 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.



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.

--
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python-ideas on gmane

[Georg Brandl]

Hi,

is there any objection against making python-ideas available on gmane?
Should I just suggest it myself, or has someone to do extra admin work
on the mailing list side?

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

-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-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Collin Winter]

On 1/10/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> 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.

Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Holden]

Collin Winter wrote:
> On 1/10/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> 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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Thomas Wouters]

On 1/10/07, Steve Holden <[EMAIL PROTECTED]> wrote:


Collin Winter wrote:
> On 1/10/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python-ideas on gmane

[Brett Cannon]

On 1/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> is there any objection against making python-ideas available on gmane?
> Should I just suggest it myself, or has someone to do extra admin work
> on the mailing list side?
>

Just email me personally the email address to subscribe.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Raymond Hettinger]

[Thomas Wouters]
>  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.

If 3.0 comes out before Py2.6, ISTM that the authorative tool for checking Py3.0
compatibility is to simply run the code in Py3.0.  Anything less is sure to 
miss 
something.

Also, the usual reasons apply for having a stand-alone pychecker/pylint tool or 
module.
As a separate tool, we can make rapid updates, add new tests, fix bugs, and 
enhance
this usability of the tool in response to user feedback.

One other thought is that warnings framework may not be the best way for a 
developer
to go about updating his or her code.  For me the warnings framework has almost
never been of use for code updates..  It is easier and more comprehensive to 
grep for
backticks or for calls to "coerce" than to run code and hope that every code 
path gets
exercised.



Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Sylvain Thénault]

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 <[EMAIL PROTECTED]> 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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[glyph]

On 07:42 pm, [EMAIL PROTECTED] wrote:
>On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> 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.

>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 could not possibly agree more.

Given the highly dynamic nature of Python, such a tool will *at best* catch 
only the most egregious uses of deprecated features.  Backticks are easy enough 
to find, but the *only* way that I can reasonably imagine migrating a body of 
code like Twisted (or any non-trivial Python library) would be having a way to 
examine the warning output of its test suite.

I am sper +1 on the warnings for 2.6, as well as forward-compatibility at 
some point in the 2.x series for new syntax.  Without the ability to bridge 
2.x->3.0 during some interim period, I can say for sure that Twisted _will not_ 
migrate to 3.0, ever.  We are really a small project and just don't have the 
manpower to maintain two overlapping but mutually incompatible codebases.

I've been assuming for some time that the only hope for Py3k compatibility 
within Twisted would be using PyPy as a translation layer.  With the addition 
of runtime compatibility warnings, it might be feasible that we could run on 
the "bare metal" (ha ha) of Python3's VM.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Holden]

Thomas Wouters wrote:
> 
> 
> On 1/10/07, *Steve Holden* <[EMAIL PROTECTED] 
> > wrote:
> 
> Collin Winter wrote:
>  > On 1/10/07, Thomas Wouters <[EMAIL PROTECTED]
> > wrote:
>  >> On 1/10/07, Raymond Hettinger < [EMAIL PROTECTED]
> > 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 h

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

[Thomas Wouters]

On 1/10/07, Steve Holden <[EMAIL PROTECTED]> wrote:


Thomas Wouters wrote:
>
>
> On 1/10/07, *Steve Holden* <[EMAIL PROTECTED]
> > wrote:
>
> Collin Winter wrote:
>  > On 1/10/07, Thomas Wouters <[EMAIL PROTECTED]
> > wrote:
>  >> On 1/10/07, Raymond Hettinger < [EMAIL PROTECTED]
> > 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.



I'm sorry, that was unintentional. I was actually replying to Colin; I took
the opportunity to reply to two mails. I'm not sure what happened, it looked
right in gmail (and still does.)

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).



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.

--
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Holden]

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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

On 10/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I've been assuming for some time that the only hope for Py3k compatibility
> within Twisted would be using PyPy as a translation layer.

Does this ring as many warning bells for me as it does for others? I
know very little about the current state of PyPy, but I read your
comment as implying that you expect Twisted to be unavailable (at some
level or other) for users of Py3K. Is that right?

How many other projects/packages anticipate *not* migrating to Py3K, I wonder?

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

On 10/01/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> Does this ring as many warning bells for me as it does for others?

... for others as it does for me ...

Doh.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Benji York]

Paul Moore wrote:
> How many other projects/packages anticipate *not* migrating to Py3K, I wonder?

I certainly can't speak for the project as a whole, but I anticipate a 
fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0.
--
Benji York
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python-ideas on gmane

[David Goodger]

[Georg Brandl]
> is there any objection against making python-ideas available on gmane?

It's already there. That's how I read it.

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Phillip J. Eby]

At 11:10 PM 1/10/2007 +, Paul Moore wrote:
>On 10/01/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I've been assuming for some time that the only hope for Py3k compatibility
> > within Twisted would be using PyPy as a translation layer.
>
>Does this ring as many warning bells for me as it does for others? I
>know very little about the current state of PyPy, but I read your
>comment as implying that you expect Twisted to be unavailable (at some
>level or other) for users of Py3K. Is that right?
>
>How many other projects/packages anticipate *not* migrating to Py3K, I wonder?

I think it's safe to say that any package of comparable size is going to 
think twice about it without transitional compatibility.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Anthony Baxter]

On Thursday 11 January 2007 07:48, Thomas Wouters wrote:
> They serve a different purpose, and it isn't taking any time away
> from me (or Anthony, I can confidently guess) working on 2to3.

Correct. Note that checking for something like dict.has_key is going 
to be far far more reliable from inside the interpreter. Heck, one 
of the PEP-3xxx's actually calls for doing this.

> > 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.

Correct. In addition, please read what I posted - these warnings are 
off by default, and won't go through the warnings mechanism at all 
unless you specify the command line flag.

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!

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Anthony Baxter]

On Thursday 11 January 2007 06:32, Georg Brandl wrote:
> I guess there are quite a few people who won't start moving to
> Python 3.0 with 2.6, or even when 3.1 is out, as long as their
> program works fine with the 2.x line. There's no need to punish
> them with extra overhead.

Checking a single C global int is hardly going to make a huge impact 
at all.


-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Raymond Hettinger]

[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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jack Diederich]

On Wed, Jan 10, 2007 at 06:04:05PM -0800, Raymond Hettinger wrote:
> [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.

I'm also a fan of not scratching something until it itches but if
someone else already feels the itch and wants to do the work +0.
The pro warnings camp has said it won't add interpreter overhead unless
you ask for it (and they are willing to test that it is so).

> 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.

No one has seriously suggested that it would be easy or if you prefer
no one serious has suggested it would be easy ;)

> As far as "reassurance that it won't be that bad to migrate", screens full
> of warnings may be less than reassuring.

If folks want to put in the effort (and people heavier than me have 
offered) to support light-weight optional warnings in addition to the
2to3 tool I can't complain.  It seems redundant to me but their time isn't
mine.

-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com