[Python-Dev] peps 329, 266, 267

Phillip J. Eby pje at telecommunity.com
Thu Apr 22 13:55:07 EDT 2004

At 12:22 PM 4/22/04 -0400, Jewett, Jim J wrote:
>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.)

But at least it was still backward-compatible with respect to what actually 
is found in the module's globals.

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

It *could*, but it's wasteful to break such programs without necessity.

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

I think you're missing the part where builtins change from one release to 
the next.  I might have had a global named 'zip' or 'enumerate' in a Python 
1.5 program, and when I upgrade to 2.4 I am now "shadowing a builtin".

More information about the Python-Dev mailing list