>I've checked in what I believe is an adequate block for at least this >particular hack. wrap_setattr(), which is called in response to ><type>.__setattr__(), now compares if the C function it is about to >call is the same as the C function in the built-in base class closest >to the object's class. This means that if B is a built-in class and P >is a Python class derived from B, P.__setattr__ can call >B.__setattr__, but not A.__setattr__ where A is an (also built-in) >base class of B (unless B inherits A.__setattr__). Does this follow __mro__ or __base__? I'm specifically wondering about the implications of multiple inheritance from more than one C base class; this sort of thing (safety checks relating to heap vs. non-heap types and the "closest" method of a particular kind) has bitten me before in relation to ZODB4's Persistence package. In that context, mixing 'type' and 'PersistentMetaClass' makes it impossible to instantiate the resulting metaclass, because neither type.__new__ nor PersistentMetaClass.__new__ is considered "safe" to execute. My "evil hack" to fix that was to add an extra PyObject * to PersistentMetaClass so that it has a larger tp_basicsize than 'type' and Python then considers it the '__base__' type, thus causing its '__new__' method to be accepted as legitimate.
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