> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4