guido 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?
+1 from here.
> - Do we really want to have built-in names for code objects, traceback
> objects, and other figments of Python's internal workings?
nope.
> - What should the argument to dict() be? A list of (key, value)
> pairs, a list of alternating keys and values, or something else?
how about supporting the following:
d == dict(d.items())
d == dict(d.keys(), d.values())
and also:
d = dict(k=v, k=v, ...)
Cheers /F
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