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

[Finn Bock]

[Guido]

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

I think that it will be difficult to avoid creating a new object under
jython because calling a type already directly calls the type's java
constructor.

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

Jython already interprets the arguments to the dict type as alternating
key/values:

>>> from types import DictType as dict
>>> dict('a', 97, 'b', 98, 'c', 99)
{'b': 98, 'a': 97, 'c': 99}
>>>

This behaviour isn't documented on the python side so it can be changed.
However, it it is necessary to maintain this API on the java side and we
have currently no way to prevent the type constructors from being
visible and callable from python. 

Whatever is decided, I hope jython can keep the current semantics of its
dict type.

regards,
finn