[Python-Dev] quick poll: could int, str, tuple etc. become type objects?

[Barry A. Warsaw]

>>>>> "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