[Python-Dev] quick poll: could int, str, tuple etc. become type objects?
Barry A. Warsaw
Tue, 5 Jun 2001 14:31:12 -0400
>>>>> "GvR" == Guido van Rossum <email@example.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
GvR> <built-in function int>
GvR> you would see
GvR> <type 'int'>
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
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
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