[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