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

[M.-A. Lemburg]

> > [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.)
> 
> -1
> 
> While this looks cute, I think it would break a lot of introspection
> code or other code which special cases Python functions for
> some reason since type(int) would no longer return
> types.BuiltinFunctionType.
> 
> If you don't like the names, why not take the change and
> create a new module which then exposes the Python class hierarchy
> (much like we did with the exceptions.py module before it was
> intregrated as C module) ?!

Looks like I'm alone with my uncertain feeling about this move...
oh well. 

BTW, we should consider having more than one contructor for an
object rather than trying to stuff all possible options and parameters
into one overloaded super-constructor. I've done this in many of
my mx extensions and have so far had great success with it (better
programming error detection, better docs, more intuitive interfaces,
etc.). In that sense, more than one way to do something will
actually help clarify what the programmer really wanted. Just 
a thought...

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/