>>>>> "NS" == Neil Schemenauer <nas@arctrix.com> writes:
NS> I've run into a problem with ExtensionClass which I believe
NS> can only be fixed by modifying Python. I will try to explain.
NS> I have an ExtensionClass which defines __cmp__. Depending on
NS> the objects being compared, the __cmp__ method may never be
NS> called. This is due to code in object.c that looks like this:
| if (PyInstance_Check(v) || PyInstance_Check(w)) {
| try to use use __cmp__ method
| }
| else {
| try number coerce and fall back on type name comparison
| }
I hit a similar wall when I tried (a long time ago) to take a boolean
class I'd written in Python and make it a built-in type. The problem
was that in Python I could compare a Boolean instance against any
other object for truth equivalence, but because of this hack, I
couldn't do the same with the built-in type.
| * Define a new type flag Py_TPFLAGS_INSTANCE.
| * Create a new predicate Py_IsInstance which checks for this
| flag.
| * Set this flag on PyInstance_Type.
| * Replace most occurances of PyInstance_Check with
| Py_IsInstance.
NS> Extension types (like ExtensionClass) can then define the type
NS> flag Py_TPLAGS_INSTANCE and be treated as an instance type by
NS> the Python interpreter. This should make it quite a bit
NS> easier to make extension types behave like "real" classes.
I'm not sure how well this addresses what I ran into. Would
PyBooleanObject then have to have it's Py_TPFLAGS_INSTANCE flag set?
Does that actually make sense? How does this interact with the rich
comparisons idea? Seems like this is a hack that doesn't quite get at
the heart of the matter, worthwhile as it may be given the current
implementation.
-Barry
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