[Python-Dev] quick poll: could int, str, tuple etc. become type objects?
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 firstname.lastname@example.org
Does your DRESSING ROOM have enough ASPARAGUS?