Armin Rigo wrote: > Hi, > > Ok, here is the reason for the leak... > > There is in scipy a type called 'int32_arrtype' which inherits from both > another scipy type called 'signedinteger_arrtype', and from 'int'. > Obscure! This is not 100% officially allowed: you are inheriting from > two C types. You're living dangerously! > > Now in this case it mostly works as expected, because the parent scipy > type has no field at all, so it's mostly like inheriting from both > 'object' and 'int' -- which is allowed, or would be if the bases were > written in the opposite order. But still, something confuses the > fragile logic of typeobject.c. (I'll leave this bit to scipy people to > debug :-) Well, I'm stumped on this. Note the method resolution order for the new scalar array type (exactly as I would expect). Why doesn't the int32 type inherit its tp_free from the early types first? a = zeros(10) type(a[0]).mro() [<type 'int32_arrtype'>, <type 'signedinteger_arrtype'>, <type 'integer_arrtype'>, <type 'numeric_arrtype'>, <type 'generic_arrtype'>, <type 'int'>, <type 'object'>]
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