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

Jewett, Jim J jim.jewett at eds.com
Thu Apr 22 12:22:22 EDT 2004

At 04:39 PM 4/21/04 -0400, Jewett, Jim J wrote:

If this is really only about globals and builtins, then you can just initialize each module's dictionary with a copy of builtins.

(Note that Raymond's original proposal was much stronger; instead of just moving builtins to globals, it moved both builtins and globals into locals.)

Phillip J. Eby:

There's only one problem with this idea, and it's a big one: 'import *' would now include all the builtins,

Why is this bad?

Because some modules are examined by software, and only the expected names belong there. For example, I believe if you run 'pydoc' on such a module, it will proceed to document all the builtins.

Fair enough. But that software could compare against builtins, and do a set-minus.

... If the other module actually has modified a builtin, you'll need to do the same ...

... just because one module shadows a builtin, doesn't mean you have to follow suit.

I did phrase that carelessly. The objects you import will still use their original module's globals. You only need to copy these when you want your own code to act consistently with the other module.

But note that import * already imports names which shadow builtins, so the only real change would be when the imported module does not shadow a builtin, but your own module does (and does so before the import, perhaps because of an earlier import *).

If you want to protect even this obscure case, import could be changed to special-case builtins.

By the way, what are people benchmarking to decide that builtin lookups are frequent enough to matter? It seems intuitively true (and probably for the same handful of builtins throughout an entire program), but pystone is contrived enough not to show much difference compared to its per-run variability.

-jJ

More information about the Python-Dev mailing list