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

Guido van Rossum guido@digicool.com
Tue, 05 Jun 2001 16:22:43 -0400


> > -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.
> 
> Looks like I'm alone with my uncertain feeling about this move...
> oh well. 

Well, I don't see how someone could be doing introspection on int and
be confused when it's not a function -- either you (think you) know
it's a function, so you use it as a function without introspecting it,
and that continues to work; or you're open to all possibilities, and
then you'll introspect it, and then you'll discover what it is.

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

Yes, but the other ways are spelled as factory functions.  Maybe,
*maybe* the other factory functions could be class-methods, but don't
hold your hopes high.

--Guido van Rossum (home page: http://www.python.org/~guido/)