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

Greg Ward gward@python.net
Tue, 5 Jun 2001 18:29:49 -0400

On 05 June 2001, Guido van Rossum said:
> 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

+1 from me too.

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

Probably not, as long as they are accessible somewhere.  I could live
with either a C-ified 'types' module or shoving these into the 'new'
module, although I think I prefer the latter slightly.

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

I love /F's suggestion

  dict(k=v, k=v, ...)

but that's icing on the cake -- cool feature, looks pretty, etc.  (And
*finally* Python will have all the syntactic sugar that Perl programmers
like to have.  ;-) I think the real answer should be

  dict(k, v, k, v)

like Jython.  If both can be supported, that would be swell.

Greg Ward - Linux geek                                  gward@python.net
Does your DRESSING ROOM have enough ASPARAGUS?