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

[Guido van Rossum]

While thinking about metatypes, I had an interesting idea.

In PEP 252 and 253 (which still need much work, please bear with me!)
I describe making classes and types more similar to each other.  In
particular, you'll be able to subclass built-in object types in much
the same way as you can subclass user-defined classes today.  One nice
property of classes is that a class is a factory function for its
instances; in other words, if C is a class, C() returns a C instance.

Now, for built-in types, it makes sense to do the same.  In my current
prototype, after "from types import *", DictType() returns an empty
dictionary and ListType() returns an empty list.  It would be nice
take this much further: IntType() could return an integer, TupleType()
could return a tuple, StringType() could return a string, and so on.
These are immutable types, so to make this useful, these constructors
need to take an argument to specify a specific value.  What should the
type of such an argument be?  It's not very interesting to require
that int(x) takes an integer argument!

Most of the popular standard types already have a constructor function
that's named after their type:

  int(), long(), float(), complex(), str(), unicode(), tuple(), list()

We could make the constructor take the same argument(s) as the
corresponding built-in function.

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

  >>> int
  <built-in function int>

you would see

  >>> int
  <type 'int'>

but otherwise the behavior would be identical.  (Note that I don't
require that a factory function returns a *new* object each time.)

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.

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?

- What should the argument to dict() be?  A list of (key, value)
  pairs, a list of alternating keys and values, or something else?

- What else?

Comments?

--Guido van Rossum (home page: http://www.python.org/~guido/)