Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
On 08:19 am, martin@v.loewis.de 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 not what I'm hearing. Python 3 is both adding new ways to do things, and removing the older way, in the same version, with no overlap. This makes me very anxious.
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 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 way, as it is not merely a new API, but a changed API.
The API isn't changed. It's just dependent on its execution context in a confusing way. That difference right now is being reflected as "2.x VM" vs. "3.0 VM" but there are other ways to reflect it more explicitly. 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() in that particular context. If the actual data structures of module dictionaries and stack objects are too expensive there are other, similar things that could be done at the C level. This implementation strategy is just the obvious thing that occurred to me after maybe 2 minutes of consideration. I'm sure someone more familiar with the internals of Python could come up with something better.
glyph@divmod.com 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() in that particular context.
Why do you think that this would be that certainly possible? I cannot imagine an efficient implementation. Regards, Martin
On 1/13/07, "Martin v. Löwis"
glyph@divmod.com 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() in that particular context.
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? If so, we're no longer arguing
about whether it's possible, but whether we want to pay the price. Given
that the dict.keys/values/items change hasn't been written and only broadly
designed, it's hard to tell *right now* what we can do to ease the
transition. I do believe we should be prepared to as much as we can, in
Python 2.6 and 2.7, to ease it (and the other transitions.) That means the
2to3 tool and warnings in appropriate places, and anything else we can do.
Including, if necessary, optionally futzing with the returned type of
dict.keys/values/items in Python 2.6, in order to make it a list-like type
that whines when it is being operated on in ways the 3.0 type won't allow.
--
Thomas Wouters
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, but whether we want to pay the price. Given that the dict.keys/values/items change hasn't been written and only broadly designed, it's hard to tell *right now* what we can do to ease the transition. I do believe we should be prepared to as much as we can, in Python 2.6 and 2.7, to ease it (and the other transitions.) That means the 2to3 tool and warnings in appropriate places, and anything else we can do.
I don't think we should do *everything* we can. If 2.6 performance will suffer significantly to support 3.x warnings, the price would be too high. Regards, Martin
participants (3)
-
"Martin v. Löwis" -
glyph＠divmod.com -
Thomas Wouters