4 kraftige funksjoner Python mangler fortsatt

Python er et levende språk - under konstant utvikling for å holde tritt med tiden. Python Software Foundation gjør ikke bare tillegg til standardbiblioteket og til referanseimplementeringen CPython, men introduserer også nye funksjoner og forbedringer til selve språket.

For eksempel introduserte Python 3.8 en ny syntaks for in-line-oppdrag ("hvalrossoperatøren") som gjør visse operasjoner mer konsise. En annen nylig godkjent syntaksforbedring, mønstermatching, vil gjøre det lettere å skrive kode som evalueres for en av mange mulige tilfeller. Begge disse funksjonene ble inspirert av deres tilstedeværelse og brukbarhet på andre språk.

Og de er bare to av en rekke nyttige funksjoner som kan legges til Python for å gjøre språket mer uttrykksfullt, kraftigere, mer egnet for den moderne programmeringsverdenen. Hva mer kan vi ønske oss? Her er fire flere språkfunksjoner som kan gi Python noe av reell verdi - to kan vi faktisk få, og to vil vi sannsynligvis ikke.

Ekte konstanter

Python har egentlig ikke konseptet med en konstant verdi. I dag er konstanter i Python stort sett et spørsmål om konvensjon. Ved å bruke et navn som er i store bokstaver og slangesaker - f.eks. DO_NOT_RESTART - er et hint om at variabelen er ment å være en konstant. Tilsvarendeå skrive.Final type kommentar gir et snev til linters om at et objekt ikke skal endres, men det håndhever det ikke under kjøretid.

Hvorfor? Fordi mutabilitet er dypt inngrodd i Pythons oppførsel. Når du tilordner en verdi til en variabel - f.eks.x = 3 - du oppretter et navn i det lokale navneområdet,x, og peker den på et objekt i systemet som har heltallverdien3. Python forutsetter til enhver tid at navn er foranderlige - det noen navnet kunne peke på noen gjenstand. Det betyr at hver gang et navn brukes, gjør Python bryet med å se opp hvilket objekt det peker på. Denne dynamikken er en av hovedårsakene til at Python kjører saktere enn noen andre språk. Pythons dynamikk gir stor fleksibilitet og bekvemmelighet, men det koster ytelse for kjøretid.

En fordel med å ha ekte konstante erklæringer i Python vil være en viss reduksjon i frekvensen av objektoppslag som foregår under kjøretid, og dermed bedre ytelse. Hvis kjøretiden på forhånd vet at en gitt verdi aldri endres, trenger den ikke å slå opp bindingen. Dette kan også gi en vei for ytterligere optimaliseringer fra tredjeparter, som systemer som genererer maskininnfødt kode fra Python-apper (Cython, Nuitka).

Imidlertid ville sanne konstanter være en stor forandring, og mest sannsynlig en tilbakestående inkompatibel endring. Det ville også være oppe til debatt om konstanter ville komme i form av ny syntaks - for eksempel den som ennå ikke er brukt$ symbol - eller som en utvidelse av Pythons eksisterende måte å erklære navn på. Til slutt er det det større, filosofiske spørsmålet om hvorvidt sanne konstanter gir mening i et språk der dynamikk har vært en stor del av anken.

Kort sagt, det er mulig at vi ser sanne konstanter i Python, men det vil være en stor brytningsendring.

Ekte overbelastning og generiske legemidler

På mange språk kan flere versjoner av den samme funksjonen skrives for å fungere med forskjellige typer input. For eksempel, atil_streng () funksjonen kan ha forskjellige implementeringer for konvertering fra heltall, flytende tall eller andre objekter - men de vil dele det samme navnet for enkelhets skyld. “Overbelastning”, eller “generikk”, gjør det lettere å skrive robust programvare, siden du kan skrive generiske metoder for vanlige prosesser i stedet for å bruke en metode spesielt for en gitt type.

Python lar deg bruke ett funksjonsnavn til å gjøre arbeidet til mange, men ikke ved å definere flere forekomster av en funksjon. Du kan definere et navn bare én gang i et gitt omfang og binde det til bare et enkelt objekt om gangen, slik at du ikke kan ha flere versjoner av en enkelt funksjon under samme navn.

Det Python-utviklere vanligvis gjør for å omgå dette, er å bruke innebygde programmerisinstance () ellertype() for å bestemme hvilken type variabel som sendes til en funksjon, og deretter foreta tiltak basert på typen. Noen ganger innebærer dette å sende til en typespesifikk versjon av en funksjon under panseret. Men denne tilnærmingen gjør det vanskelig for andre utviklere å utvide funksjonen din med mindre du går ut av veien for å gjøre den utvidbar - for eksempel ved å sende til metoder innen en klasse, som kan bli underklassert.

PEP 3124, avansert i april 2007, foreslo en mekanisme for å dekorere funksjoner for å indikere at de kunne bli overbelastet. Forslaget ble utsatt i stedet for å bli avvist direkte - noe som betyr at ideen var grunnleggende sunn, men tiden var ikke riktig for å implementere den. En faktor som kan fremskynde adopsjonen av overbelastning i Python - eller føre til at ideen blir helt ryddet - er implementeringen av det nylig foreslåtte mønstertilpasningssystemet.

I teorien kan mønstermatching brukes under panseret for å håndtere utsendelse av overbelastning. Imidlertid kan mønstermatching også gis som en begrunnelse for ikke implementering av generikk i Python, siden det allerede gir en elegant måte å sende operasjoner basert på typesignaturer.

Så vi kan få ekte overbelastning i Python en dag, eller fordelene kan bli erstattet av andre mekanismer.

Optimering av halerekursjon

Mange språkkompilatorer bruker hale-rekursjonsoptimaliseringer, der funksjoner som kaller seg ikke skaper nye stabelrammer i applikasjonen, og dermed risikerer å sprenge bunken hvis de løper for lenge. Python gjør ikke dette, og faktisk har skaperne konsekvent kommet imot å gjøre det.

En grunn er at mye av Python, fra innsiden og ut, brukeriterasjon heller ennrekursjon - generatorer, coroutines og så videre. I dette tilfellet betyr det å bruke en funksjon med en sløyfe og en stakkstruktur i stedet for en rekursiv mekanisme. Hver samtale i sløyfen kan lagres i en stabel for å opprette en ny rekursjon, og spratt av stabelen når rekursjonen er ferdig.

Python-utviklere oppfordres til å bruke disse mønstrene i stedet for rekursjon, så det virker lite håp om rekursjonsoptimaliseringer. Sjansene her er ikke sannsynlige i det hele tatt, ettersom Pythons uttrykk støtter andre løsninger.

Multiline lambdas

Lambdas, eller anonyme funksjoner, gjorde det til Python bare etter litt motstand fra språkskaperen Guido van Rossum. Ettersom Python-lambdas eksisterer nå, er de svært begrensede: De lar deg bare bruke et enkelt uttrykk (i det vesentlige alt til høyre for et likhetstegn i en oppdragsoperasjon) som funksjonslegeme. Hvis du vil ha en fullstendig blokk med uttalelser, er det bare å bryte dem ut og gjøre en faktisk funksjon av dem.

Årsaken kommer til utformingen av språket slik van Rossum ser det. Som van Rossum skrev i 2006, “Jeg finnernoen en uakseptabel løsning som bygger en innrykkbasert blokk midt i et uttrykk. Siden jeg synes alternativ syntaks for setningsgruppering (f.eks. Seler eller begynner / slutter nøkkelord) er like uakseptabelt, gjør dette ganske mye en multiline lambda til et uløselig puslespill. "

Problemet er med andre ord ikke teknisk, men mangelen på en syntaks for multiline lambdas som utfyller den eksisterende estetikken til Python-syntaks. Det er sannsynligvis ingen måte å gjøre det på som ikke innebærer å lage en spesiell sak, og et språk som påløper spesielle tilfeller har en tendens til å bli ubehagelig å bruke. Inntil en slik enhjørning vises, må vi bare nøye oss med separat definerte funksjoner.

Multiline lambdas skjer sannsynligvis ikke i Python.