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

[M.-A. Lemburg]

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/