PEP-505: Draft (Coalescing Operators)
I've finally finished a reasonably complete draft of PEP-505. It's taken me longer than I expected due to work and also a new addition to our family :) I tried to keep the PEP humorous; but please don't mistake silliness for a lack of seriousness. Let's try to keep separate two different debates: (1) the utility of the proposed operators (2) how to spell them. Arguing about #2 is a waste of time if #1 is a non-starter. If we can achieve some consensus on #1, then with Guido's consent, I think the next logical step would be to conduct a survey of opinions about proposed spellings, just as the authors of PEP-308 did. The survey is a data-gathering exercise, of course, not a democratic vote. The PEP has more details on that. I envision the PEP as being severable: it might be accepted in whole, in part, or not at all. For this reason, there are quite a few alternatives proposed, and some of them are mutually conflicting. The conflicts aren't a problem unless and until any parts of the proposal get the green light. (Again, similar to PEP-308.) https://www.python.org/dev/peps/pep-0505/ -- Mark E. Haase
Hi Mark, I'm confused by the example
2 or None ✊🍆 err()
The PEP states this raises, but since 2 is already True, and you state that the operator has higher precedence than 'or', this example shouldn't evaluate anything to the right of 'or', so it shouldn't raise -- just like "2 or err()" doesn't raise. Also, unrelated (but in the same section) I think this operator should have a precedence higher than 'not'. That is,
not x ✊🍆 y
should be parsed as
not (x ✊🍆 y)
After all, if we parsed it as
(not x) ✊🍆 y
it wouldn't be very useful, since (not x) never returns None, hence y would never be evaluated here -- this is a redundant way to spell (not x). Other notes: "The idea of a None -aware function invocation syntax was discussed on python- ideas, but the idea was rejected by BDFL." -- I don't think it's that strong. It's merely that the use cases for x?.attr and x?[key] are stronger, and various people suggested to focus on the most important. "[...] except it returns its left operand if that operand is None and otherwise returns the right operand." -- the part about returning the left operand if it is None is silly -- there is only one None, so it should just say "returns None if the left operand is None and otherwise returns the right operand." I'll have to think more about the rest. -- --Guido van Rossum (python.org/~guido)
Yes, that `or` example is incorrect. I have short circuiting and precedence jumbled up in my head, but thinking about that example has improved my understanding. I will fix that and incorporate your other notes shortly. Thanks! On Thu, Oct 22, 2015 at 12:13 PM, Guido van Rossum <guido@python.org> wrote:
-- Mark E. Haase 202-815-0201
Hi Mark, I'm confused by the example
2 or None ✊🍆 err()
The PEP states this raises, but since 2 is already True, and you state that the operator has higher precedence than 'or', this example shouldn't evaluate anything to the right of 'or', so it shouldn't raise -- just like "2 or err()" doesn't raise. Also, unrelated (but in the same section) I think this operator should have a precedence higher than 'not'. That is,
not x ✊🍆 y
should be parsed as
not (x ✊🍆 y)
After all, if we parsed it as
(not x) ✊🍆 y
it wouldn't be very useful, since (not x) never returns None, hence y would never be evaluated here -- this is a redundant way to spell (not x). Other notes: "The idea of a None -aware function invocation syntax was discussed on python- ideas, but the idea was rejected by BDFL." -- I don't think it's that strong. It's merely that the use cases for x?.attr and x?[key] are stronger, and various people suggested to focus on the most important. "[...] except it returns its left operand if that operand is None and otherwise returns the right operand." -- the part about returning the left operand if it is None is silly -- there is only one None, so it should just say "returns None if the left operand is None and otherwise returns the right operand." I'll have to think more about the rest. -- --Guido van Rossum (python.org/~guido)
Yes, that `or` example is incorrect. I have short circuiting and precedence jumbled up in my head, but thinking about that example has improved my understanding. I will fix that and incorporate your other notes shortly. Thanks! On Thu, Oct 22, 2015 at 12:13 PM, Guido van Rossum <guido@python.org> wrote:
-- Mark E. Haase 202-815-0201
participants (2)
-
Guido van Rossum -
Mark E. Haase