[Python-Dev] peps 329, 266, 267

Phillip J. Eby pje at telecommunity.com
Wed Apr 21 16:54:34 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.  (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?

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.

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

*shudder*  I'm glad the language really doesn't work in the way you just 
described.  :)  No, just because one module shadows a builtin, doesn't mean 
you have to follow suit.

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

__debug__ is also a builtin, in the sense of being optimizable by the 
compiler, so I don't see any reason to look at it differently.  In fact, 
isn't __debug__ *already* treated as a constant by the compilers?

Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
 >>> __debug__
 >>> __debug__=0
SyntaxError: can not assign to __debug__ (<pyshell#1>, line 1)

Yep, I guess so.

More information about the Python-Dev mailing list