Andrew Barnert added the comment: > IMO allowing any special method to be set to None seems to make more trouble > than it is worth.
That's exactly why allowing _any_ special method to be None is a separate issue (#25958). Most special methods don't have any corresponding problem to the one with __reversed__. > Ideally I think it would be better to require __reversed__() for reverse() to > work, but such a change would break compatibility. See the -ideas thread "Deprecating the old-style sequence protocol" (http://article.gmane.org/gmane.comp.python.ideas/37588). > Regarding test_enumerate.py, your class looks like this: Please look at the two classes directly above it in the same function. The new Blocked exactly parallels the existing NoLen. > I suggest either remove __getitem__() if it serves no purpose It very definitely serves a purpose. The whole point of the new test is that reversed will not fall back to using __getitem__ and __len__ if __reversed__ is None. So __getitem__ has to be there; otherwise, we already know (from the NoGetItem test) that it wouldn't get called anyway. This is exactly the same as the NoLen test, which verifies that __reversed__ will not fall back to __getitem__ and __len__ if one is present but not both. > , or change it to something like this if you really want an unreversible > sequence: Sure, if I wanted a real class that could be used as a sequence but could not be reversed. But all I want here is a toy class for testing the specific method lookup behavior. Again, exactly like the existing classes in the same test. Finally, from your previous comment: > I think the ABC documentation should clarify which methods are checked for > None and which aren’t. Looking at this a bit more: The ABC documentation doesn't even tell you that, e.g., Container and Hashable have subclass hooks that automatically make any class with __contains__ and __hash__ act like registered subclasses while, say, Sequence and Set don't. So, you're suggesting that we should explain where the hooks in some of those types differ, when we haven't even mentioned where the hooks exist at all. Maybe collections.abc _should_ have more detail in the docs, but I don't think that should be part of this bug. (Practically, I've always found the link to the source at the top sufficient--trying to work out exactly why tuple meets some ABC and some custom third-party sequence doesn't, which is a pretty rare case to begin with, is also pretty easy to deal with: you scan the source, quickly find that Sequence.register(tuple), read up on what it does, and realize that collections.abc.Sequence.register(joeschmoe.JoeSchmoeSequence) is what you want, and you're done.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25864> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
