"Don't rebind built-in names*" - it confuses readers

[Steven D'Aprano]

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