On 05 June 2001, Guido van Rossum said:
> 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
+1 from me too.
> 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.
Cool!
> There are details to be worked out, e.g.
>
> - Do we really want to have built-in names for code objects, traceback
> objects, and other figments of Python's internal workings?
Probably not, as long as they are accessible somewhere. I could live
with either a C-ified 'types' module or shoving these into the 'new'
module, although I think I prefer the latter slightly.
> - What should the argument to dict() be? A list of (key, value)
> pairs, a list of alternating keys and values, or something else?
I love /F's suggestion
dict(k=v, k=v, ...)
but that's icing on the cake -- cool feature, looks pretty, etc. (And
*finally* Python will have all the syntactic sugar that Perl programmers
like to have. ;-) I think the real answer should be
dict(k, v, k, v)
like Jython. If both can be supported, that would be swell.
Greg
--
Greg Ward - Linux geek gward@python.net
http://starship.python.net/~gward/
Does your DRESSING ROOM have enough ASPARAGUS?
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