Re: [Python-Dev] cpython: Issue 14814: Correctly return NotImplemented from ipaddress._BaseNetwork.__eq__
On Sat, 7 Jul 2012 15:08:42 +0200 (CEST) nick.coghlan <python-checkins@python.org> wrote:
I think the isinstance() test was correct. If you have an object which duck-types IPNetwork, you probably want its __eq__ to be called, not yours. Regards Antoine.
On Sat, Jul 7, 2012 at 11:55 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
This change was just to bring IPNetwork in line with the other types in the module and to stop it throwing TypeError itself, which meant the RHS was never even getting a chance to affect the result. Ducktyping and operator overloading has always been a tricky area though. If you use isinstance() checks, then the other side has to know how to reimplement your equality check, or temporarily create a real instance to do the comparison. If you use ducktyping internally, then the other side *has* to use inheritance if they want to completely control the result, but also have the option to just expose the appropriate attributes in order to interoperate with your class. The standard library tends to be a mixture of both based on how integral the author feels the ordering and comparison behaviour is to the classes involved. In this case, I currently think internal ducktyping is the right answer, but I'm open to being persuaded otherwise. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jul 8, 2012 at 12:59 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hmm, I just noticed the __lt__ implementations still throw TypeError directly (at least in the IPNetwork case). Looks like some more cleanups are still needed in this area :P Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Jul 7, 2012 at 11:55 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
This change was just to bring IPNetwork in line with the other types in the module and to stop it throwing TypeError itself, which meant the RHS was never even getting a chance to affect the result. Ducktyping and operator overloading has always been a tricky area though. If you use isinstance() checks, then the other side has to know how to reimplement your equality check, or temporarily create a real instance to do the comparison. If you use ducktyping internally, then the other side *has* to use inheritance if they want to completely control the result, but also have the option to just expose the appropriate attributes in order to interoperate with your class. The standard library tends to be a mixture of both based on how integral the author feels the ordering and comparison behaviour is to the classes involved. In this case, I currently think internal ducktyping is the right answer, but I'm open to being persuaded otherwise. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jul 8, 2012 at 12:59 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Hmm, I just noticed the __lt__ implementations still throw TypeError directly (at least in the IPNetwork case). Looks like some more cleanups are still needed in this area :P Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
Antoine Pitrou -
Nick Coghlan