[Python-Dev] peps 329, 266, 267
Jewett, Jim J
jim.jewett at eds.com
Wed Apr 21 16:39:10 EDT 2004
>> If this is really only about globals and builtins,
>> then you can just initialize each module's dictionary
>> with a copy of builtins. (Or cache them in the module
>> __dict__ on the first lookup, since you know where it
>> would have gone.)
Phillip J. Eby:
> Interesting thought. The same process that currently
> loads the __builtins__ member could instead update the
> namespace directly.
> There's only one problem with this idea, and it's a big
> one: 'import *' would now include all the builtins,
> causing one module's builtins (or changes thereto) to
> propagate to other modules.
Why is this bad?
The reason to import * is that you intend to use the
module's members as if they were your own. If the
other module actually has modified a builtin, you'll
need to do the same, or the imported members won't
work quite right.
If you're sure you don't want everything the other
module changed, then you shouldn't be using *.
If you absolutely have to use * but not get builtins
changed, then you can reupdate from builtins after
> ... declare that the any builtin used in a module
> that's known to be a builtin, is allowed to be
> optimized to the meaning of that builtin.
> In effect, '__builtins__' should be considered an
> implementation detail, not part of the language,
Many builtins (None, True, KeyError) are effectively
keywords, and I would agree.
Others, like __debug__, are really used for
intermodule communication, because there isn't
any other truly global namespace. (Perhaps
there should be a conventional place to look,
such as a settings module?)
More information about the Python-Dev