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

Ka-Ping Yee ping@lfw.org
Tue, 5 Jun 2001 12:41:22 -0500 (CDT)


On Tue, 5 Jun 2001, Guido van Rossum wrote:
> 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'>

I'm all in favour of this.  In fact, i had the impression that you
were planning to do exactly this all along.  I seem to recall some
conversation about this a long time ago -- am i dreaming?

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

I would love this.

> - Do we really want to have built-in names for code objects, traceback
>   objects, and other figments of Python's internal workings?

Perhaps we would only provide built-in names for objects that are
commonly constructed.  For things like code objects that are never
user-constructed, their type objects could be set aside in a module.

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

A list of (key, value) pairs.  It's the only sensible choice, given
that dict.items() is the obvious way to get all the information out
of a dictionary into a list.


-- ?!ng