> > [Guido] > > Now invoke the Zen of Python: "There should be one-- and preferably > > only one --obvious way to do it." So why not make these built-in > > functions *be* the corresponding types? Then instead of > > > > >>> int > > <built-in function int> > > > > you would see > > > > >>> int > > <type 'int'> > > > > but otherwise the behavior would be identical. (Note that I don't > > require that a factory function returns a *new* object each time.) > > -1 > > While this looks cute, I think it would break a lot of introspection > code or other code which special cases Python functions for > some reason since type(int) would no longer return > types.BuiltinFunctionType. > > If you don't like the names, why not take the change and > create a new module which then exposes the Python class hierarchy > (much like we did with the exceptions.py module before it was > intregrated as C module) ?! Looks like I'm alone with my uncertain feeling about this move... oh well. BTW, we should consider having more than one contructor for an object rather than trying to stuff all possible options and parameters into one overloaded super-constructor. I've done this in many of my mx extensions and have so far had great success with it (better programming error detection, better docs, more intuitive interfaces, etc.). In that sense, more than one way to do something will actually help clarify what the programmer really wanted. Just a thought... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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