[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