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

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > > -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.

Ok, let's put it in another way:

The point is that your are changing the type of very basic building
parts in Python and that is likely to cause failure in places
which will most likely be hard to find to fix.

Becides we don't really gain anything from replacing builtin 
functions with classes (to the contrary: we lose some, since we 
can no longer use the function call optimizations for builtins and
have to go through all the generic call mechanism code instead).

Also, have you considered the effects this has on restricted
execution mode ? 

What will happen if someone replaces the builtins with special
versions which hide some security relevant objects, e.g. open()
is a prominent candidate for this.

Why not put the type objects into a separate module instead
of reusing the builtins ?

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

No... why make things complicated when simple functions work just
fine as factories. Multilpe constructors on a class would make
subclassing a pain...

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