-1. Assertions are ignored when Python is run with -O, so we definitely
don't want to encourage relying on asserts to ensure users pass the correct
value. But even if that wasn't an issue, I consider the `else:
ValueError()` to be significantly more readable.
Otherwise, the alternative offered by
On 03/07/2020 00:39, Artemis wrote:
Often, I know that a variable should have one of a set of values, and I want to
determine which one, with an if/elif/else clause. This looks something like
this:
```
if foo == 1:
# do a
elif foo == 2:
# do b
elif foo == 3:
# do c
else:
r
An alternative way of doing what you need that doesn't add any syntax, is more
readable, runs faster, scales better and has long been used as the reason that
python doesn't need a case statement would be:
# Dictionary of which actions to take for foo
foo_action_dict = {
'a':a,
'b':b,
> Assertions aren't guaranteed to be executed and thus should never be used
where raising an error is required.
Hence *roughly* equivalent to. Perhaps for this reason the second version would
be confusing and should not be used.
> `else: raise SomeError('reason')` already has the desired effect,
To be more specific, if the last `elif` condition permits all remaining
permissible conditions (which I suppose would just be whatever is asserted
by the proposed syntax), then the else block can just be the raising of the
exception.
On Thu, Jul 2, 2020, 7:52 PM Steele Farnsworth
wrote:
> Assert
Assertions aren't guaranteed to be executed and thus should never be used
where raising an error is required.
`else: raise SomeError('reason')` already has the desired effect, and it's
plenty readable.
On Thu, Jul 2, 2020, 7:46 PM Artemis wrote:
> Often, I know that a variable should have one o