Single type for __builtins__ in Py3.0
Christopher Subich
csubich.spamblock at subich.spam.com.block
Fri Sep 23 14:50:04 EDT 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