[Python-Dev] Odd new-style class __new__ behavior
Guido van Rossum
guido@python.org
Sat, 30 Mar 2002 13:27:20 -0500
> On 30 Mar 2002, Michael Hudson wrote:
> > Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > > Suppose I define:
> > >
> > > class Foo(object):
> > > def __new__(cls):
> > > return 1
> > >
> > > class Bar(object):
> > > def __new__(cls):
> > > return [1,2,3]
> > >
> > > Python 2.2 returns:
> > > print Foo()
> > > > 1
> > > print Bar()
> > > > []
> > >
> > > I would expect that Bar() should return [1,2,3]. Am I running into some
> > > clever undocumented feature or a bug?
> >
> > Is tp_init being called on the returned list?
Correct.
> I suspect that the object construction code would check the result
> of tp_new to see if the expected type. If not, tp_init should not
> be called on the instance. I suspect that this check must already
> be there, or else none of these cases would work at all.
It calls the tp_init of the returned type.
> Anyhow, I won't know what is really happening for sure until Monday,
> when I can run this through gdb. However, some more data points:
> returning dictionaries, tuples, strings, classic object instances,
> and user-defined new-style classes all seem to work. Only lists
> seem to behave this way.
Because only lists have a tp_init that resets the object.
> Guido, can you clarify what the "correct behavior" should be for the
> above cases? Once I know that, I will happily supply a corrective
> patch if one is necessary.
Correct behavior is not to return a different type unless you know
what its __init__ does.
We're going to document each type's __new__ and __init__, and you're
welcome to help.
--Guido van Rossum (home page: http://www.python.org/~guido/)