Single type for __builtins__ in Py3.0

[Collin Winter]

Hallo all,

As it currently stands, the type of the global __builtins__ differs
depending on whether you're in the __main__ namespace (__builtins__ is
a module) or not (its a dict). I was recently tripped up by this
discrepancy, and googling the issue brings up half-a-dozen or so c.l.p
threads where others have been bitten by this, too.

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.

Thanks,
Collin Winter

[1] http://mail.python.org/pipermail/python-list/2002-May/103613.html
[2] http://www.python.org/doc/2.4.1/ref/naming.html

 

[Michael Hoffman]

If possible, I'd like to see this go in before 3.0.

+1

 

[Tom Anderson]

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

Perhaps __builtins__ should be a magic module which could be accessed
using subscripting as well as proper names (__builtins__["int"] as well as
__builtins__.int), to avoid breakage. AFAICT, there's no easy way to do
this at the moment: defining __getitem__ in a module doesn't give you a
working [] operator on it. Have i screwed that up? If not, might it be
possible to change this, so modules are treated the same as any other
object in terms of handling []? I admit that this is the only use case for
it, and it's a pretty weak one, but it would be good to be consistent, i
think.

If this gets a good response, I'll kick it up to python-dev.

+1

tom

 

[Christopher Subich]

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.

 

[Collin Winter]

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.

In all cases (eval, exec, execfile), the globals parameter must be a
dict and the locals can be any mapping object, so the value of the
__builtins__ key would just need to be a module (could be created with
the "new" module). This is about the same breakage as with any other
code using __builtins__.

One possibility would be to deprecate the dict-form. This could be
done as Tom Anderson suggests, by supporting both __getattr__ and
__getitem__, with the latter issuing a deprecation warning for a
while. My tests indicate that this is possible, with both module.attr
and module['item'] forms available.

Collin Winter