Re: [Python-Dev] The bytes type
On 1/12/07, Mike Orr <[EMAIL PROTECTED]> wrote: On 1/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The benefit (to me, and to many others) of 3.x over 2.x is the promise of > more future maintenance, not the lack of cruft. The benefit (to me, and to many others) of 3.x over 2.x is the promise of getting rid of cruft. If we're going to re-add cruft for the sake of temporary compatibility, we may as well just stick with 2.x. You have to take a quantum leap sometimes or you end up working around the same old mistakes. There seems to be rather a lot of confusion. No one is suggesting Python 3.0be anything less for the sake of backward compatibility. Instead, it has been suggested Python 2.6 (and possibly 2.7) be something *more* in order to provide for an easier upgrade path. No compromises in Python 3.0. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] 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
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 > 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 <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] 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
> 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 ___ Python-Dev mailing list [email protected] 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
[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 implementation is impossible, but I
still don't see it. The ones you suggest don't work that well:
> * Don't make it a dictionary key; make it an attribute of the module at
> the C level.
Unfortunately, in a function, there is no reference to the module it
came from. There is __module__ (on the function, not on the code
object), but that is a string.
> * Annotate the code object in some way that makes code compiled in that
> scope set a global variable to enable the compatibility; protect it with
> the GIL.
This I don't quite understand: what has the GIL to do with that? Are you
suggesting to hold the GIL while the entire function is running?
That would restrict concurrency even more than the GIL already restricts
it. Also, what about nested functions spanning multiple modules (with
different settings)?
> * These methods are already function pointers in a data structure in C;
> actually have a py->py3k mode switch which swaps out the C function
> pointers to the appropriate implementation for the calling code.
That doesn't work: The items method is per dictionary (or actually per
type, i.e. for the dict type). The same dictionary, when accessed from
different modules, should have .items() behave differently. Wrt. that
property:
# a.py
from __future__ import items_is_iter
def f(d):
return d.items
# b.oy
import a
d = {}
print a.f(d)()
What should that print?
I think I take back my earlier suggestion that I can imagine an
inefficient implementation. I cannot imagine any reasonable behaviour
of a per-module change of methods on dictionary objects.
> 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.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
