[Python-Dev] Switch statement
Phillip J. Eby
pje at telecommunity.com
Fri Jun 23 20:27:18 CEST 2006
At 07:51 PM 6/23/2006 +0200, M.-A. Lemburg wrote:
>Furthermore, the compiler could do other optimizations on the
>const declared names, such as optimizing away global lookups
>and turning them into code object constants lookups.
Technically, they'd have to become LOAD_DEREF on cells set up by the module
level code and attached to function objects. 'marshal' won't be able to
save function references or other such objects to a .pyc file.
It's interesting that this line of thinking does get us closer to the
long-desired builtins optimization. I'm envisioning:
or something like that. Hm. Maybe:
from __builtin__ import static *
In practice, however, this doesn't work for * imports unless it causes all
global-scope names with no statically detectable assignments to become
static. That could be a problem for modules that generate symbols
dynamically, like 'opcode' in the stdlib.
OTOH, maybe we could just have a LOAD_STATIC opcode that works like
LOAD_DEREF but falls back to using globals if the cell is empty.
Interestingly, a side effect of making names static is that they also
become private and untouchable from outside the module.
Hm. Did I miss something, or did we just solve builtin lookup
optimization? The only problem I see is that currently you can stick a new
version of 'len()' into a module from outside it, shadowing the
builtin. Under this scheme (of making all read-only names in a module
become closure variables), such an assignment would change the globals, but
have no effect on the module's behavior, which would be tied to the static
definitions created at import time.
>Professional Python Services directly from the Source (#1, Jun 23 2006)
> >>> Python/Zope Consulting and Support ... http://www.egenix.com/
> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
>::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
>Python-Dev mailing list
>Python-Dev at python.org
More information about the Python-Dev