Single type for __builtins__ in Py3.0

Christopher Subich csubich.spamblock at
Fri Sep 23 20:50:04 CEST 2005

Collin Winter wrote:
> Hallo all,
> I'd like to propose that in Py3.0 (if not earlier), __builtins__ will
> be the same type regardless of which namespace you're in. Tim Peters
> has said [1] that the reason __builtins__ in __main__ is a module so
> that "the curious don't get flooded with output when doing vars() at
> the prompt". Based on this, I propose that __builtins__ be a module
> (really, an alias for the __builtin__ module as it is now) in all
> namespaces.
> If possible, I'd like to see this go in before 3.0. The reference
> manual currently states [2] that __builtins__ can be either a dict or
> a module, so changing it to always be a module would still be in
> keeping with this. However, I realise that there's probably code out
> there that hasn't been written to deal with both types, so this would
> result in some minor breakage (though it would be easily fixable).
> If this gets a good response, I'll kick it up to python-dev.

A few questions:

How would this change, if made in a minimal way, impact the "provide 
alternate globals() and locals() to eval and exec" feature?  Altering 
__builtins__ is a half-assed way of providing some sort of security, but 
it's probably useful in preventing user-supplied code from shooting 
itself in the foot without aiming first.

Secondly, wouldn't this also be a good time to implement modules as 
actual objects, so (e.g) modules could provide a __getattribute__ for 
references of the form modname.thing?

If the change can't be made without breaking the altering of 
__builtins__ for exec/eval, then I'm -0.5.  Otherwise, +1, and the 
second bit is probably good for further debate.

More information about the Python-list mailing list