>>>>> "GvR" == Guido van Rossum <guido@digicool.com> writes:
GvR> Now invoke the Zen of Python: "There should be one-- and
GvR> preferably only one --obvious way to do it." So why not make
GvR> these built-in functions *be* the corresponding types? Then
GvR> instead of
>> int
GvR> <built-in function int>
GvR> you would see
>> int
GvR> <type 'int'>
+1
GvR> but otherwise the behavior would be identical. (Note that I
GvR> don't require that a factory function returns a *new* object
GvR> each time.)
GvR> If we did this for all built-in types, we'd have to add maybe
GvR> a dozen new built-in names -- I think that's no big deal and
GvR> actually helps naming types. The types module, with its
GvR> awkward names and usage, can be deprecated.
I'm a little concerned about this, since the names that would be added
are probably in common use as variable and/or argument names. I.e. At
one point `list' was a very common identifier in Mailman, and I'm sure
`dict' is used quite often still. I guess this would be okay as long
as working code doesn't break because of it.
OTOH, I've had fewer needs for a dict builtin (though not non-zero),
and easily zero needs for traceback objects, code objects, etc.
GvR> There are details to be worked out, e.g.
GvR> - Do we really want to have built-in names for code objects,
GvR> traceback objects, and other figments of Python's internal
GvR> workings?
I'd say no. However, we could probably C-ify the types module, a la,
the exceptions module, and that would be the logical place to put the
type factories.
GvR> - What should the argument to dict() be? A list of (key,
GvR> value) pairs, a list of alternating keys and values, or
GvR> something else?
You definitely want to at least accept a sequence of key/value
2-tuples, so that d.items() can be retransformed into a dictionary
object.
-Barry
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