On Mon, Jan 15, 2007 at 11:40:22PM +0100, Martin v. L??wis wrote:
Do I just suffer from having an overactive imagination? Are all of
these implementation strategies impossible for some reason, and there
are no others?
Yes, and yes.
What about turning all references to obj.items into the
A.M. Kuchling schrieb:
What about turning all references to obj.items into the equivalent
bytecode for this:
if isinstance(obj, dict): # XXX should this be 'type(obj) is dict'?
if 2.x behaviour: _temp = obj.items
elif 3.x behaviour: _temp = obj.iteritems
else:
_temp = obj.items
Martin v. Löwis wrote:
It would still suffer from the cross-module issue:
# a.py
from __future__ import items_is_iterator
def f(d):
return d.items
# b.py
import a
d = {}
print a.f(d)
For compatibility with 2.x, a.f should really return a bound
method that returns lists; for
On 1/13/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schrieb:
It would certainly be possible to have:
from __future__ import items_is_iter
be the same as:
__py3k_compat_items_is_iter__ = True
and have the 2.x series' items() method check the globals() of the
Why do you think that this would be that certainly possible?
I cannot imagine an efficient implementation.
Ah, but can you imagine an inefficient one?
I think so (although one can never know until it's implemented).
If so, we're no longer
arguing about whether it's possible,
[EMAIL PROTECTED] schrieb:
Also, the exact strategy I suggested could be implemented in various
ways that might be efficient. Here are a few ways it might be made more
efficient than the straw many of one extra dict lookup per call to
keys() et. al.:
I'm not saying that an efficient
[EMAIL PROTECTED] writes:
On 10:12 am, [EMAIL PROTECTED] wrote:
For practical reasons (we have enough work to be getting on with) PyPy
is more-or-less ignoring Python 2.5 at the moment. After funding and
so on, when there's less pressure, maybe it will seem worth it. Not
soon though.
I
Anthony Baxter schrieb:
There's a couple of ways I see it - we could add a -3 command line
flag to enable 3.x compat, or maybe a from __future__ statement.
Although the latter would be a global thing, which is different to
how all existing from __future__s work, so probably not good.
[EMAIL PROTECTED] schrieb:
It would certainly be possible to have:
from __future__ import items_is_iter
be the same as:
__py3k_compat_items_is_iter__ = True
and have the 2.x series' items() method check the globals() of the
calling scope to identify the return value of items()
[EMAIL PROTECTED] schrieb:
There will certainly be demand for an asynchronous server in 3.0,
To flip the question around: there might be a demand for Twisted in 3.0,
but will there be a demand for 3.0 in Twisted? It might just be easier
for everyone concerned to just continue maintaining 2.x
On 08:19 am, [EMAIL PROTECTED] wrote:
Georg Brandl schrieb:
If Python 3.0 was simply a release which removed deprecated features,
there would clearly be no issue. I would update my code in advance of
the 3.0 release to not use any of those features being removed, and
I'm all set. But that's
On Friday 12 January 2007 19:19, Martin v. Löwis wrote:
Georg Brandl schrieb:
It has always been planned that in those cases that allow it,
the new way to do it will be introduced in a 2.x release too,
and the old way removed only in 3.x.
What does that mean for the example James gave: if
Georg Brandl [EMAIL PROTECTED] writes:
Armin Rigo schrieb:
Hi Paul,
On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to Py3K, I
wonder?
FWIW: Psyco.
What will PyPy do? It will certainly support compiling Py3k code
On 11 Jan, 08:22 pm, [EMAIL PROTECTED] wrote:
On 1/11/07, James Y Knight [EMAIL PROTECTED] wrote:
If the goal is really to have Py 3.0 be released later this year,
There will certainly be demand for an asynchronous server in 3.0,
To flip the question around: there might be a demand for Twisted
On 01:12 am, [EMAIL PROTECTED] wrote:
On Friday 12 January 2007 06:09, James Y Knight wrote:
On Jan 10, 2007, at 6:46 PM, Benji York wrote:
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
On 07:56 am, [EMAIL PROTECTED] wrote:
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
It's worse than that. This
On 10:12 am, [EMAIL PROTECTED] wrote:
For practical reasons (we have enough work to be getting on with) PyPy
is more-or-less ignoring Python 2.5 at the moment. After funding and
so on, when there's less pressure, maybe it will seem worth it. Not
soon though.
I think I know what you mean from
On Friday 12 January 2007 21:42, [EMAIL PROTECTED] wrote:
If the plan is to provide a smooth transition, it would help a
lot to have this plan of foward and backward compatibility
documented somewhere very public. It's hard to find information
on Py3K right now, even if you know your way
On 11:22 am, [EMAIL PROTECTED] wrote:
FWIW, I also agree with James that Python 3 shouldn't even be
released until the 2.x series has reached parity with its feature
set. However, if there's continuity in the version numbers
instead of the release dates, I can at least explain to Twisted
Martin v. Löwis schrieb:
Georg Brandl schrieb:
If Python 3.0 was simply a release which removed deprecated features,
there would clearly be no issue. I would update my code in advance of
the 3.0 release to not use any of those features being removed, and
I'm all set. But that's not what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote:
Well, that is one of the cases in which that won't be possible ;)
I think there will be at least three areas that will make porting a
challenge:
- - APIs where the semantics have changed instead
At 11:59 AM 1/12/2007 +, [EMAIL PROTECTED] wrote:
In order to do this, everything that has been changed in 3.0 has to have
some mechanism for working both ways in some 2.x release. I phrased this
as its feature set because I am not aware of any new functionality in
3.0 that simply isn't
On 1/12/07, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 12, 2007, at 9:17 AM, Georg Brandl wrote:
Well, that is one of the cases in which that won't be possible ;)
I think there will be at least three areas that will make porting a
On 1/12/07, Steven Bethard [EMAIL PROTECTED] wrote:
Yeah, when this was talked about last time, I wrote PEP 3002 which
requests exactly this:
http://www.python.org/dev/peps/pep-3002/
It basically proposes that all backwards-incompatible changes be
discussed in a PEP somewhere, and that
Georg Brandl wrote:
Martin v. Löwis schrieb:
What does that mean for the example James gave: if dict.items is
going to be an iterator in 3.0, what 2.x version can make it return
an iterator, when it currently returns a list?
There simply can't be a 2.x version that *introduces* the new
On 09:04 pm, [EMAIL PROTECTED] wrote:
I'm wondering if we might be going the wrong way about warning about
compatibility between 2.x and 3.x. Perhaps it might be better if the 3.0
alpha had a 2.x compatibility mode command-line flag, which is removed late
in the beta cycle.
Please, no.
I don't
On 10 Jan, 11:10 pm, [EMAIL PROTECTED] 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
On Jan 10, 2007, at 6:46 PM, Benji York wrote:
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.
I (another
James Y Knight schrieb:
If Python 3.0 was simply a release which removed deprecated features,
there would clearly be no issue. I would update my code in advance of
the 3.0 release to not use any of those features being removed, and
I'm all set. But that's not what I'm hearing. Python 3
On 1/11/07, James Y Knight [EMAIL PROTECTED] wrote:
If the goal is really to have Py 3.0 be released later this year,
3.0 alpha is scheduled for this year. 3.0 final is not scheduled till
next year, and of course another level of tweaks will have to be made
after it's been in the Real World for
Hi Paul,
On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to Py3K, I wonder?
FWIW: Psyco.
Armin
___
Python-Dev mailing list
Python-Dev@python.org
Armin Rigo schrieb:
Hi Paul,
On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to Py3K, I
wonder?
FWIW: Psyco.
What will PyPy do? It will certainly support compiling Py3k code at some point,
but will the codebase
On Jan 11, 2007, at 8:12 PM, Anthony Baxter wrote:
I'm plan to try and make the transition as painless as possible.
I'm glad to hear it.
The goal is to have a first alpha sometime this year - there is
absolutely no chance of a 3.0 final this year.
Duly noted.
Basically: my plea is: please
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.
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
-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
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
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
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
[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.
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?
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.
Thomas Wouters wrote:
On 1/10/07, *Steve Holden* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Collin Winter wrote:
On 1/10/07, Thomas Wouters [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On 1/10/07, Raymond Hettinger [EMAIL PROTECTED]
mailto:[EMAIL
On 1/10/07, Steve Holden [EMAIL PROTECTED] wrote:
Thomas Wouters wrote:
On 1/10/07, *Steve Holden* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Collin Winter wrote:
On 1/10/07, Thomas Wouters [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On 1/10/07, Raymond
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
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
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
___
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
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
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
[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
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
cc'ing python-dev - followups should probably go there, rather than
the p3yk list.
So here's my latest plan:
- Add a Py3KDeprecationWarning, as a subclass of DeprecationWarning
(or maybe just of Warning)
- Add a -W py3k shortcut, which is the same as
-W once:Py3kDeprecationWarning
- Add a C
53 matches
Mail list logo
