Ono to vychází pomaleji a čím větší je rozsah hodnot, tím to je horší:
cnt = 0
for i in range(100000):
if i in range(1000, 1500):
cnt += 1
print(cnt)
vs.
cnt = 0
for i in range(100000):
if 1000 <= i < 1500:
cnt += 1
print(cnt)
$ time python3 t1.py 500 real 0m0.075s user 0m0.073s sys 0m0.001s $ time python3 t2.py 500 real 0m0.048s user 0m0.043s sys 0m0.004s
a přitom za mě zásadní je dodržet konvenci (i tu nepsanou) podle okolního kódu a celého projektu. Pokud se všude používá jeden a ten stejný zápis např. těhle range podmínek, není vhodné při každé implementaci přemýšlet a hledat optimánější řešení a dělat divergenci v rámci kódu, snižuje to pak přehlednost a zvyšuje pravděpodobnost chyb v okrajových případech.
Při volbě optimálnější cesty (z jakéhokoliv pohledu) je pro mě důležité provést refaktor napříč celým kódem s patřičným zdůvodněním (to je důležité, např. range v py2 není tentýž jako v py3, tak je dobré při přechodu znovu vyhodnotit podmínky a nebrát stav jako konstantu).
ten guard (podle toho jak to čtu v odkázaném dokumentu) má výhodu v momentě, kdy těch případů je více, pokud bys zanořoval if, tak už je pozdě vyskočit ven do jiného case.
case [num] if num > 10 and num < 15:
case [num] if num >= 15 and num < 20:
Pro tyhle účely je asi nepodstatné jaká varianta podmínky se použije.
v pristich verzich se planuje obecnejsi mechanismus, kdy pujde implementovat neco jako inRange(1, 3)
https://www.python.org/dev/peps/pep-0622/#custom-matching-protocol
v soucasnosti jde matchovat objekty jen podle atributu.