4 výkonné funkce Python stále chybí

Python je živý jazyk - neustále se vyvíjí, aby držel krok s dobou. Python Software Foundation neprovádí pouze doplnění standardní knihovny a referenční implementace CPython, ale také zavádí nové funkce a vylepšení samotného jazyka.

Například Python 3.8 představil novou syntaxi pro in-line přiřazení („operátor mrože“), díky níž jsou některé operace stručnější. Další nově schválené vylepšení syntaxe, shoda vzorů, usnadní psaní kódu, který vyhodnotí jeden z mnoha možných případů. Obě tyto funkce byly inspirovány jejich přítomností a užitečností v jiných jazycích.

A jsou to jen dvě ze spousty užitečných funkcí, které lze přidat do Pythonu, aby byl jazyk expresivnější, výkonnější a vhodnější pro moderní programovací svět. Co jiného bychom si mohli přát? Tady jsou další čtyři jazykové funkce, které by mohly Pythonu přidat něco skutečně hodnotného - dva, které bychom mohli skutečně získat, a dva pravděpodobně ne.

Pravdivé konstanty

Python ve skutečnosti nemá koncept konstantní hodnoty. Dnes jsou konstanty v Pythonu většinou věcí konvence. Používání názvu, který je uveden ve velkých písmenech a v hadím případě - např. DO_NOT_RESTART - je náznak, že proměnná má být konstantní. Podobněpsaní. Konečné anotace typu poskytuje náznakům linterů, že objekt by neměl být upravován, ale nevynucuje to za běhu.

Proč? Protože proměnlivost je hluboce zakořeněna v chování Pythonu. Když proměnné přiřadíte hodnotu - např.x = 3 - vytváříte jméno v místním jmenném prostoru,Xa namířeno na objekt v systému, který má celočíselnou hodnotu3. Python vždy předpokládá, že jména jsou proměnlivá - to žádný jméno by mohlo ukazovat na žádný objekt. To znamená, že při každém použití jména se Python potýká s hledáním toho, na jaký objekt ukazuje. Tato dynamika je jedním z hlavních důvodů, proč Python běží pomaleji než některé jiné jazyky. Dynamika Pythonu nabízí velkou flexibilitu a pohodlí, ale stojí to za cenu běhového výkonu.

Jednou z výhod skutečných deklarací konstanty v Pythonu by bylo určité snížení frekvence vyhledávání objektů, které probíhá za běhu, a tím lepší výkon. Pokud runtime předem ví, že se daná hodnota nikdy nezmění, nemusí vyhledávat její vazby. To by také mohlo poskytnout cestu k dalším optimalizacím třetích stran, jako jsou systémy, které generují strojově nativní kód z aplikací Pythonu (Cython, Nuitka).

Skutečné konstanty by však byly zásadní změnou a pravděpodobně zpětně nekompatibilní změnou. Bylo by také na diskusi, kdyby konstanty přicházely prostřednictvím nové syntaxe - například dosud nevyužité$ symbol - nebo jako rozšíření existujícího způsobu Pythonu k deklaraci jmen. Nakonec je tu širší filozofická otázka, zda mají skutečné konstanty smysl v jazyce, kde je dynamismus velkou částí odvolání.

Stručně řečeno, je možné, že v Pythonu uvidíme skutečné konstanty, ale byla by to zásadní zlomová změna.

Skutečné přetížení a generika

V mnoha jazycích lze napsat více verzí stejné funkce pro práci s různými druhy vstupu. Například ato_string () funkce může mít různé implementace pro převod z celých čísel, čísel s plovoucí desetinnou čárkou nebo jiných objektů - ale kvůli pohodlí by sdílely stejný název. „Přetížení“ nebo „generika“ usnadňuje psaní robustního softwaru, protože můžete psát obecné metody pro běžné procesy, spíše než použít metodu konkrétně pro daný typ.

Python vám umožňuje používat jeden název funkce k práci mnoha, ale ne definováním více instancí funkce. V daném oboru můžete definovat název pouze jednou a vázat jej pouze na jeden objekt najednou, takže pod stejným názvem nemůžete mít více verzí jedné funkce.

To, co vývojáři Pythonu obvykle dělají, aby to vyřešili, je použití vestavěných funkcíisinstance () nebotyp() Chcete-li určit typ proměnné odeslané funkci, proveďte akci na základě typu. Někdy to zahrnuje odeslání na typově specifickou verzi funkce pod kapotou. Ale tento přístup ostatním vývojářům ztěžuje rozšíření vaší funkce, pokud se vám nepodaří ji rozšířit - například odesláním metodám v rámci třídy, které lze podtřídy.

PEP 3124, pokročilý v dubnu 2007, navrhl mechanismus pro zdobení funkcí, který naznačuje, že by mohly být přetíženy. Návrh byl spíše odložen než přímo zamítnut - myšlenka byla v zásadě správná, ale nebyl vhodný čas na její provedení. Jedním z faktorů, které by mohly urychlit přijetí přetížení v Pythonu - nebo způsobit, že se myšlenka úplně zbaví - je implementace nově navrženého systému porovnávání vzorů.

Teoreticky by se pod kapotou dalo použít párování vzorů, které by zvládlo odeslání přetížení. Srovnávání vzorů však lze uvést také jako zdůvodnění ne implementace generik v Pythonu, protože již poskytuje elegantní způsob odesílání operací na základě podpisů typů.

Mohli bychom tedy jednoho dne získat skutečné přetížení v Pythonu, nebo by jeho výhody mohly být nahrazeny jinými mechanismy.

Optimalizace rekurze ocasu

Mnoho překladačů jazyků využívá optimalizace rekurze ocasu, kde funkce, které si říkají, nevytvářejí v aplikaci nové rámce zásobníku, a tak riskují vyhodení zásobníku do vzduchu, pokud běží příliš dlouho. Python to nedělá a ve skutečnosti se jeho tvůrci důsledně postavili proti tomu.

Jedním z důvodů je to, že velká část Pythonu se používá zevnitř venopakování spíše nežrekurze - generátory, korutiny atd. V tomto případě to znamená použít místo rekurzivního mechanismu funkci se smyčkou a strukturou zásobníku. Každé volání smyčky lze uložit do zásobníku a vytvořit tak novou rekurzi a po dokončení rekurze vyskočit ze zásobníku.

Vývojářům Pythonu se doporučuje používat tyto vzory místo rekurze, takže se zdá, že existuje malá naděje na optimalizaci rekurze. Šance zde nejsou vůbec pravděpodobné, protože Pythonovy idiomy podporují jiná řešení.

Víceřádkové lambdy

Lambdas neboli anonymní funkce se do Pythonu dostali až po jistém odporu ze strany tvůrce jazyků Guida van Rossuma. Protože nyní existují lambdy Pythonu, jsou velmi omezené: Umožňují vám použít pouze jediný výraz (v podstatě cokoli napravo od znaménka rovnosti v operaci přiřazení) jako tělo funkce. Pokud chcete celý blok výpisů, jednoduše je rozdělte a vytvořte z nich skutečnou funkci.

Důvodem je design jazyka, jak ho vidí van Rossum. Jak napsal van Rossum v roce 2006, „zjišťujižádný nepřijatelné řešení, které uprostřed výrazu vloží blok založený na odsazení. Jelikož považuji alternativní syntaxi pro seskupování příkazů (např. Složené závorky nebo klíčová slova pro začátek / konec) za stejně nepřijatelnou, dělá to z víceřádkové lambdy neřešitelnou hádanku. “

Jinými slovy, problém není technický, ale nedostatek syntaxe pro víceřádkové lambdy, který by doplnil stávající estetiku syntaxe Pythonu. Pravděpodobně neexistuje způsob, jak to udělat, který nezahrnuje vytvoření zvláštního případu, a jazyk, ve kterém se zvláštní případy vyskytují, se obvykle stává nepříjemným. Dokud se takový jednorožec neobjeví, musíme si vystačit s odděleně definovanými funkcemi.

Víceřádkové lambdy se v Pythonu pravděpodobně nedělají.