Guido van Rossum wrote:
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.)
-1 While this looks cute, I think it would break a lot of introspection code or other code which special cases Python functions for some reason since type(int) would no longer return types.BuiltinFunctionType. If you don't like the names, why not take the change and create a new module which then exposes the Python class hierarchy (much like we did with the exceptions.py module before it was intregrated as C module) ?!
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?
Not really.
- What should the argument to dict() be? A list of (key, value) pairs, a list of alternating keys and values, or something else?
As function, I'd say: take either a sequence of tuples or another dictionary as argument. mxTools already has such a function, BTW. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/