Tvůrci jazyka Python připravují nový návrh PEP 622, který by konečně přinesl do Pythonu syntaxi příkazu porovnávání vzorů. Nové příkazy pro porovnávání vzorů by programátorům Pythonu poskytli expresivnější způsoby zpracování strukturovaných dat, aniž by se museli uchýlit k řešení.
Porovnávání vzorů je běžnou vlastností mnoha programovacích jazyků, například vypínač / pouzdro v C. Umožňuje provést jednu z řady možných akcí na základě hodnoty dané proměnné nebo výrazu. Zatímco Pythonu chyběla nativní syntaxe pro porovnávání vzorů, bylo možné ji emulovatif / elif / else řetězy nebo vyhledávání slovníku.
PEP 622 navrhuje metodu pro porovnání výrazu s řadou druhů vzorů pomocí a shodný případ syntax:
porovnat něco: případ 0 | 1 | 2: malá písmena („malé číslo“) [] | [_]: print ("Krátká sekvence") case str () | bytes (): print ("Něco jako řetězec") case _: print ("Něco jiného")Podporované typy shody vzorů zahrnují literály, názvy, konstantní hodnoty, sekvence, mapování (v zásadě přítomnost páru klíč-hodnota ve výrazu), třídu, směs výše uvedených nebo jakýkoli z těchto plus podmíněných výrazů. Jakákoli shoda, která je nejednoznačná nebo jej nelze vyřešit, vyvolá za běhu výjimku.
Objekty mohou zpracovávat testy shody pomocí nového protokolu zvaného __zápas__ protokol. Pokud objekt implementuje __zápas__ Tuto metodu lze použít k otestování, zda odpovídá danému vzoru třídy, a vrácení příslušné odpovědi.
PEP 622 by také umožnil kontrolám statického typu ověřit, zda lze ověřit shody. Nový @ zapečetěné dekorátor pro třídu označuje psaní typu, že jakákoli podtřída dané třídy je definována ve stejném modulu jako základní třída.
Předchozí PEP pro přidání shody vzorů - PEP 275 a PEP 3103, navržené v letech 2001 a 2006 - byly odmítnuty kvůli nedostatku podpory veřejnosti. PEP 3103 navrhl tvůrce Pythonu Guido van Rossum. Nový PEP, jehož autorem je van Rossum a několik dalších, si klade za cíl poskytnout regulární výrazy pro porovnávání objektů, spíše než jen jednoduchý if / elif / else náhradní. Autoři poznamenávají, že mnoho aspektů tohoto PEP bylo inspirováno tím, jak funguje párování vzorů v Rust a Scale.
O tom, jak by se to všechno implementovalo pod kapotou, se ještě diskutuje. Implementace navržená v PEP 622 by generovala stejné sekvence bytecode jako if / elif / else řetěz. Větší vypínač / pouzdro bloky se mohly stát méně výkonnými v závislosti na tom, kolik podmíněné logiky bylo zahrnuto v každém z nich případ. PEP však objasňuje, že na stole je stále libovolný počet přístupů a optimalizací výkonu (např. Memoizace).
I kdyby PEP nakonec byl přijat, mohlo by se toho hodně změnit. Jednou z otázek, které budou pravděpodobně zpochybněny, je použití případ _: namísto jiný: jako závěrečná univerzální klauzule propřepínač prohlášení._ se v mnoha kontextech používá jako dočasná proměnná a jednostranné přepsání jeho chování může být pro vývojáře turnoffem.
