> From: Ethan Furman > Sent: Tuesday, June 07, 2016 1:38 PM > To: Python Dev > Subject: [Python-Dev] Proper way to specify that a method is not defined for > a type
(Just so everyone follows, this is a followup of http://bugs.python.org/issue27242 ) > For binary methods, such as __add__, either do not implement or return > NotImplemented if the other operand/class is not supported. > > For non-binary methods, simply do not define. > > Except for subclasses when the super-class defines __hash__ and the > subclass is not hashable -- then set __hash__ to None. Should I mention the __hash__ special case in the NotImplemented/NotImplementedError docs? If people are looking for a way to declare this specific operation undefined, they'd find it there as well as the hash() documentation. > Question: > > Are there any other methods that should be set to None to tell the > run-time that the method is not supported? Or is this a general > mechanism for subclasses to declare any method is unsupported? There was a discussion on one of Python-ideas or Python-dev some time ago about exactly that, but I don't think any consensus was reached. However, I think it would make sense for e.g. __iter__ and __reversed__ to tell the interpreter to *not* fall back to the default sequence protocol (well, in practice that already works, but it gives an unhelpful error message). I'm not sure how useful it would be for arbitrary methods, though. __bytes__ (which originally sparked the issue) may or may not be a good candidate, I'm not sure. While I like the `__magic_method__ = None` approach, I think the main reason __hash__ supports that is because there are legitimate use cases of disallowing hashing (i.e. mutable objects which may or may not change hash during their lifetime), but I don't think the same rationale applies to everything ("accidentally" iterating over a not-meant-to-be-iterable object will result in nonsensical data, but it won't bite the user later, unlike changing hashes which definitely will). > -- > ~Ethan~ Special-cases-aren't-special-enough-but-they're-still-there'ly yrs, -Emanuel _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
