On Tue, 5 Jun 2001, Guido van Rossum wrote: > 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'> I'm all in favour of this. In fact, i had the impression that you were planning to do exactly this all along. I seem to recall some conversation about this a long time ago -- am i dreaming? > If we did this for all built-in types, we'd have to add maybe a dozen > new built-in names -- I think that's no big deal and actually helps > naming types. The types module, with its awkward names and usage, can > be deprecated. I would love this. > - Do we really want to have built-in names for code objects, traceback > objects, and other figments of Python's internal workings? Perhaps we would only provide built-in names for objects that are commonly constructed. For things like code objects that are never user-constructed, their type objects could be set aside in a module. > - What should the argument to dict() be? A list of (key, value) > pairs, a list of alternating keys and values, or something else? A list of (key, value) pairs. It's the only sensible choice, given that dict.items() is the obvious way to get all the information out of a dictionary into a list. -- ?!ng
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