[Python-Dev] peps 329, 266, 267 (original) (raw)

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 the import.

... 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?)

-jJ

More information about the Python-Dev mailing list