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 <[EMAIL PROTECTED]> 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? _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
