This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan.furman
Recipients eric.araujo, ethan.furman, ezio.melotti, georg.brandl, gvanrossum, python-dev, r.david.murray, rhettinger, tim.peters
Date 2014-11-04.07:06:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1415084781.77.0.328926001659.issue22780@psf.upfronthosting.co.za>
In-reply-to
Content
Thank you, Raymond, both for your concern and your discretion.

My interest in changing the "can" or "may" to "should" is that, whatever the original intent of the PEP, the way Python works /now/ is that any class that doesn't return NotImplemented when it /should/ is not going to interoperate well with other compatible classes.

At the heart of the issue is what happens when

  def bin_op(self, other):
     ...

is called, but the left-hand operand doesn't know how to work with the right-hand operand?

We have three choices:

  - do nothing, letting any exceptions boil up or errors propagate

  - do a check on 'other' to determine if it's usable, and raise an exception
    if it is not

  - do a check on 'other' to determine if it's usable, and return NotImplemented
    if it is not

Only the last choice allows 'other' to also try the operation.  Except for the special-case of in-place bin-ops, why would we not want choice three?
History
Date User Action Args
2014-11-04 07:06:21ethan.furmansetrecipients: + ethan.furman, gvanrossum, tim.peters, georg.brandl, rhettinger, ezio.melotti, eric.araujo, r.david.murray, python-dev
2014-11-04 07:06:21ethan.furmansetmessageid: <1415084781.77.0.328926001659.issue22780@psf.upfronthosting.co.za>
2014-11-04 07:06:21ethan.furmanlinkissue22780 messages
2014-11-04 07:06:21ethan.furmancreate