[Guido]
> This kind of thing happens everywhere -- instances always define all
> slots but using the slots sometimes fails when the corresponding
> __foo__ doesn't exist. Decisions based on the presence or absence of
> a slot are therefore in general not reliable; the only exception is
> the decision to *call* the slot or not. The correct solution is not
> to catch AttributeError and pretend that the slot didn't exist (which
> would mask an AttributeError occurring inside the __contains__ method
> if there was one),
Ya, it sucks. I was inspired by that instance_contains() itself makes
dubious assumptions about what an AttributeError means when the functions
*it* calls raise it <wink>.
> but to reimplement the default behavior in the instance slot
> implementation.
The "backward compatibility" comment in instance_contains() was scary:
compatibility with *what*? instance_contains() is pretty darn new. I
assumed it meant there was *some* good (but unidentified) reason we had to
use PyObject_Cmp() instead of PyObject_RichCompareBool(..., Py_EQ) if
instance_item() "worked". But I haven't thought of one, except to ensure
that
some_complex in some_instance_with___getitem__
continues to blow up -- but that's not a good reason. So:
> In this case, that means that PySequence_Contains() can be simplified
> (no need to test for AttributeError), and instance_contains() should
> fall back to a loop over iter(self) rather than trying to use
> instance_item().
Will do!
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