>
> No, the conditional branching would be based on exists.__bool__ (or,
> in the current working draft, is_not_none.__bool__), and that would be
> "0 is not None", which would be True and hence short-circuit.
>
>
> `__then__` is responsible for *unwrapping* the original value from the
> circuit breaker when it short-circuits: it's what allows the overall
> expression to return "0", even though the truth check is done based on
> "0 is not None".
>
I see. I somehow missed that exists was a wrapping class rather than an
evaluating function.
---
Should you be concerned about cases where a CircuitBreaker class is used
without the `else` operator? For example, if a user accidentally does
something like:
x = exists(input_value) or default_value
If input_value is not None, the user will get an `exists` object instead of
their input value.
I'm worried that the distinction between `or` and `else` will not be
obvious. It seems like `else` will effectively just be `or`, but with more
functionality.
---
I'm also still not convinced about the reasons to avoid implementing this
on `or`. I'll address the points from the rationale:
> defining a shared protocol for both and and or was confusing, as
__then__ was the short-circuiting outcome for or , while__else__ was the
short-circuiting outcome for and
I wonder: Could the protocol be defined in terms of `or`, with DeMorgan's
law applied behind the scenes in the case of `and`?
ie:
existing(x) and existing(y) => missing(y) or missing(x)
> the and and or operators have a long established and stable meaning, so
readers would inevitably be surprised if their meaning now became dependent
on the type of the left operand. Even new users would be confused by this
change due to 25+ years of teaching material that assumes the current
well-known semantics for these operators
With basic pass-through implementations for __then__ and __else__ attached
to all classes by default, and the existing __bool__, it seems like `or`
would continue to function in the same way it currently does.
There are plenty of current dunder methods that are already redefined in
ways that might confuse people: % on strings, set operators, etc.
> Python interpreter implementations, including CPython, have taken
advantage of the existing semantics of and and or when defining runtime and
compile time optimisations, which would all need to be reviewed and
potentially discarded if the semantics of those operations changed
I can't really speak to any of this, not being familiar with the internals
of any implementation. Though, it might work out that some of the code for
handling `and` and `or` could be thrown out, since those operators would be
transformed into conditional expressions.
I very much understand the desire to not break working, optimized
implementations. However, this feels a little flimsy as a reason for
introducing new syntax.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
