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