[Python-Dev] __builtin__ vs __builtins__

Neal Norwitz nnorwitz at gmail.com
Tue Dec 13 04:38:39 CET 2005


Below is Guido's response to my question: Can we start getting rid of
__builtins__ (or __builtin__) at least for py3k?

Having both builtin versions is confusing, how can we improve the situation?

n

---------- Forwarded message ----------
From: Guido van Rossum <guido at python.org>


Couple of loose thoughts:

- Having __builtins__ and __builtin__ both is clearly a bad idea.

- Long ago, __builtin__ was just called builtin; I'm not sure I still
agree with the reasoning that made me change it. After all, we don't
have __sys__. But we *do* have __main__, and __builtin__ is special at
least in the sense that modifying it has a global effect. (But then
again, so does modifying sys.) I still think the case for __main__ is
much stronger than for __builtin__ and wouldn't mind renaming the
latter back to builtin.

- Making __builtins__ always be a dict would simplify some code; but
it really means that vars() must be hacked to suppress it in
interactive mode; I really wouldn't like to see the output of vars()
include the entire __builtins__ dict.

- Another alternative might be to merge the __builtin__ and
__builtins__ functionality (and call it __builtin__). This would slow
down some stuff (always one extra indirection to get from __builtin__
to __builtin__.__dict__ which is where the built-ins are looked up)
but that could be fixed by caching __builtin__.__dict__ in the C frame
(I'm fine with the rule that you can't modify your own __builtin__; I
think that rule already exists).

- This is probably worth a few smart people mulling it over some
more... Python-dev?


More information about the Python-Dev mailing list