Guido van Rossum wrote: >>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. I am talking about what mxTools is doing: adding new builtins to the interpreter by placing them into the __builtins__ dictionary. While I agree that it is usually better to use something like 'from x import *' or even naming the tools explicitly, some features in mxTools do warrant being made builtins, e.g. irange() has been most helpful in the past :-) Note that I'm not talking about overriding existing builtins. mxTools just adds a few more (that's what I meant with "extending builtins"). >>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. I presume you mean the case that foo.open is not already defined in foo. That's good. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jun 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 14 days left
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