On 9 November 2016 at 02:15, Steven D'Aprano <st...@pearwood.info> wrote:
> Whew! Nick, this is a big, complex PEP, and thank you for taking the > time to write it. Thanks :) > But its also hard to understand -- there's a lot of > detail, and there are places where it is easy for the reader to get > mislead by their assumptions and only get corrected deep, deep into the > PEP. At least that's my experience. This is another reason why I think the symmetric proposal I mentioned in the Risk and Concerns section may actually be a better idea, since it aligns better with the full "LHS if COND else RHS" spelling. It does make the short-circuiting more complex to explain, but if I went back to that I'd also reinstate Mark's explanation of how the short-circuiting would work and the associated diagram. > I think I'd find this PEP easier to understand if it were split into > two, like Guido's type-hints PEPs: one to explain the protocol, and one > to detail the new built-ins and syntactic sugar which rely on the > protocol. Or maybe that's just me. It's hard to explain the protocol without concrete examples to draw on, and `operator.true` and `operator.false` aren't really sufficient for that purpose (since they're more likely to elicit a reaction of "But that's the way conditional expressions work anyway..."). > I really like this PEP as a way of introducing configurable short- > circuiting behaviour, without messing with `and` and `or`. That's > really, really nice. I like your decision to keep the ?. and ?[] sugar, > as short-cuts for code based on this Circuit Breaker protocol. > > But I cannot support the exists() and missing() builtins as they stand. > I think the circuit breakers themselves work well as a concept, but: > > - I think that the names will be more harmful than helpful; I did consider the possible misinterpretation in terms of NameError, but probably didn't give it sufficient credence (since it isn't going to be immediately obvious to everyone that there's no way to readily delegate that check to a callable of any kind in Python, especially when other languages do offer that kind of "undefined" check) > - I don't think that having to explicitly call a circuit breaker is a > good substitute for the ?? operator. I think the "line signal to noise ratio" measures in the examples do a pretty decent job of highlighting that - the patterns involved are still quite verbose when using a named circuit breaker. In the next revision, I'll update the PEP to say it doesn't compete with 505 at all, and merely offers a proposal for making that PEP a semantically protocol based one. > If I absolutely had to choose between this and nothing, I'd say +1 for > this. But if I had to choose between ?? as a operator, and a generic > circuit breaking protocol with no operator but exists() builtin instead, > well, that would be a really hard decision. One of the reasons I was keen to get this written relatively quickly (aside from wanting to see for myself whether or not it actually hung together as a coherent design concept) was so we'd have plenty of time to consider the risks, opportunities and alternatives between now and 3.7. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
