"Don't rebind built-in names*" - it confuses readers
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Wed Jun 12 21:23:27 EDT 2013
On Wed, 12 Jun 2013 17:26:43 -0700, Mark Janssen wrote:
>> The builtins don't need to be imported, but they're identifiers like
>> anything else. They're a namespace that gets searched after
>> module-globals.
>
> Yes, I understand, though for clarity and separability, it seems that
> having them in a namespace that gets explicitly pulled into the global
> space is less messy, despite the extra step (the default python
> distribution could include a STARTUP file that imports the builtin
> types).
No. Having a separate builtin namespace is a design feature.
In Python, every module has it's own global namespace. Within module X,
globals() is dfferent from within module Y. (So it's not really globally-
global, it's only locally-global, if you like.) This is a Very Good Thing
-- it means that each module is compartmentalised away from every other,
by default.
Python does have a globally-global namespace. It is called "builtins",
and you're not supposed to touch it. Of course, being Python, you can if
you want, but if you do, you are responsible for whatever toes you shoot
off.
Modifying builtins will effect *all modules*. That's normally too much,
although it can very, very, very occasionally be useful. Especially in
testing and debugging. But a module can *shadow* the builtins, by simply
defining a name that matches a builtin name, without affecting any other
module. So for example, the re module defines a function compile, which
shadows the built-in compile, but:
- the re module doesn't use the built-in compile
- other modules normally use the fully-qualified re.compile
so, in practice, there is no conflict.
--
Steven
More information about the Python-list
mailing list