[Python-Dev] peps 329, 266, 267

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