I didn't realize the similarity of the proposals. I do think that testing for existence is better than running a method (that might not exist), at least from a high level perspective.So PEP 335 might be dusted off again and run through benchmarks? There seems to be at least a test implementation for Python 2.3, are there benchmarks documented somewhere? It sound like the version that adds new byte codes instead of an additional byte code per op was never included.I do like the cleanliness of not adding extra operators with nearly identical meanings.
On Monday, November 30, 2015 at 11:24:12 AM UTC-6, Guido van Rossum wrote:On Mon, Nov 30, 2015 at 8:22 AM, Henry Schreiner <henrysch...@gmail.com> wrote:--Sorry, the order was incorrect in that last message. It should be:When x and y is written, if x has __booland__, then x.__booland__(y) is returned. If not, then return x if x==False else if x==True, then if y has y.__rbooland__(x), that is returned. If not, then return yThis proposal isn't significantly different from PEP 335. In PEP 335, first you ask the left operand whether to overload 'and' or not (by calling its __and1__); if it says yes, you evaluate the second arg and ask the first to evaluate it. In your proposal, the first question is answered by inspecting whether x defines __booland__. I don't think this makes much practical difference. The second part of your proposal is just a renaming of __and2__/__rand2__ to __booland__/__rbooland__. I'm not sure I like this much; the return type of these methods is almost never going to be an actual bool, so the 'bool' in the name is somewhat misleading. (The names chosen in PEP 335 are intentionally free of semantic hints, since the intuition of someone who encounters these for the first time isn't likely to be useful.)--Guido van Rossum (python.org/~guido)