[Python-ideas] Optimizing builtins

Cesare Di Mauro cesare.di.mauro at gmail.com
Sun Jan 2 07:22:36 CET 2011

2011/1/1 Guido van Rossum <guido at python.org>

> On Sat, Jan 1, 2011 at 1:52 AM, Cesare Di Mauro
> > Do we consider local variable removing (due to internal optimizations) a
> > safe or unsafe operation?
> I would consider it safe unless the function locals() is called
> directly in the function -- always assuming the compiler does not see
> obvious other evidence (like a local being used by a nested function).

The problem here is that locals is a builtin function, not a keyword, so the
compiler must resort to something like the "code fork" that I showed before,
if we want to keep the correct language semantic.

> Still, I wonder if it isn't much better to try to do this using a JIT
>  instead of messing with the bytecode.

Ditto for me, if a good (and not resource hungry) JIT will come.

> You'll find that the current
> compiler just really doesn't have the datastructures needed to do
>  these kind of optimizations right.

Right. Not now, but something can be made if and only if it makes sense. A
JIT can make it non-sense, of course.

> Do we consider local variable values "untouchable"? Think about a locals()
> > call that return a list for a variable; lists are mutable objects, so
> they
> > can be changed by the caller, but the internally generated bytecode can
> work
> > on a "private" (on stack) copy which doesn't "see" the changes made due
> to
> > the locals() call.
> Are you sure? locals() makes only a shallow copy, so changes to the
> list's contents made via the list returned by locals() should be
> completely visible by the bytecode.

> --Guido van Rossum (python.org/~guido)

Nice to know it. Reading from the doc (
http://docs.python.org/library/functions.html#locals ) it was not clear for
me. Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110102/17ab7d5e/attachment.html>

More information about the Python-ideas mailing list