[Python-ideas] PEP 532: A circuit breaking operator and protocol

[Nick Coghlan]

On 9 November 2016 at 02:15, Steven D'Aprano <steve at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia