> 1. Extending builtins should still be possible like it is now. > > Of course, the extensions wouldn't take part in the optimizations > you have in mind, but they should still be found. I'm not sure what you mean by "extending builtins", but if it is what I think it is, I am strongly opposed. The builtins should have fixed capabilities (in a particular Python version). If you want a function that behaves just like a builtin but also can do something else, give it a different name and import it explicitly, don't override the existing entry in __builtin__. If you have a new function that you want to use in lots of code, resist the temptation to add it to the __builtin__ module. Zope did this e.g. with get_transaction() and the net result was reader confusion and intractable dependencies on import order. > 2. What happens if a new Python version introduces new builtins > that are in use by some modules out there for other purposes ? *** THIS IS NOT AFFECTED! *** There is no proposal on the table to ban the use of identifiers known to be built-ins for any purpose. If a module defines a class, function or variable that shadows a builtin name, that's fine, because the parser has no problem detecting this situation. The *only* thing being banned is insertion of a new name that shadows a builtin from outside a module. IOW: # module foo def open(): return ... is fine, but import foo foo.open = 42 is not. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4