4 kraftfulde funktioner Python mangler stadig

Python er et levende sprog - under konstant udvikling for at holde trit med tiden. Python Software Foundation tilføjer ikke kun standardbiblioteket og referenceimplementeringen CPython, men introducerer også nye funktioner og forbedringer til selve sproget.

For eksempel introducerede Python 3.8 en ny syntaks for in-line-opgaver ("hvalrosoperatøren"), der gør visse operationer mere koncise. En anden nyligt godkendt syntaksforbedring, mønstermatchning, gør det lettere at skrive kode, der evalueres for en af mange mulige tilfælde. Begge disse funktioner blev inspireret af deres tilstedeværelse og brugbarhed på andre sprog.

Og de er kun to af en række nyttige funktioner, der kan føjes til Python for at gøre sproget mere ekspressivt, mere kraftfuldt og mere egnet til den moderne programmeringsverden. Hvad kan vi ellers ønske os? Her er yderligere fire sprogfunktioner, der kan tilføje noget af reel værdi til Python - to får vi måske, og to får vi sandsynligvis ikke.

Ægte konstanter

Python har ikke rigtig begrebet en konstant værdi. I dag er konstanter i Python for det meste et spørgsmål om konvention. Brug af et navn, der er i al-caps og slangetaske - f.eks. DO_NOT_RESTART - er et tip om, at variabelen er beregnet til at være en konstant. Tilsvarende erat skrive. endelig typebetegnelse giver et tip til linters, at et objekt ikke skal ændres, men det håndhæves ikke ved kørselstid.

Hvorfor? Fordi mutabilitet er dybt forankret i Pythons adfærd. Når du tildeler en værdi til en variabel - f.eks.x = 3 - du opretter et navn i det lokale navneområde,xog pege på et objekt i systemet, der har heltalsværdien3. Python antager til enhver tid, at navne kan ændres - det nogen navn kunne pege på nogen objekt. Det betyder, at hver gang et navn bruges, går Python i besværet med at se på, hvilket objekt det peger på. Denne dynamik er en af hovedårsagerne til, at Python kører langsommere end nogle andre sprog. Pythons dynamik giver stor fleksibilitet og bekvemmelighed, men det koster prisen for runtime-ydeevne.

En fordel ved at have ægte konstante erklæringer i Python ville være en vis reduktion i hyppigheden af objektopslag, der finder sted under kørsel, og dermed bedre ydeevne. Hvis køretiden på forhånd ved, at en given værdi aldrig ændres, behøver den ikke at slå dens bindinger op. Dette kunne også give en mulighed for yderligere tredjepartsoptimeringer, som f.eks. Systemer, der genererer maskinindfødt kode fra Python-apps (Cython, Nuitka).

Imidlertid ville sande konstanter være en større ændring og sandsynligvis en bagudkompatibel ændring. Det ville også være op til debat, hvis konstanter ville komme i form af ny syntaks - for eksempel den endnu ikke anvendte$ symbol - eller som en udvidelse af Pythons eksisterende måde at erklære navne på. Endelig er der det større, filosofiske spørgsmål om, hvorvidt sande konstanter giver mening i et sprog, hvor dynamik har været en stor del af appellen.

Kort sagt, det er muligt, at vi ser ægte konstanter i Python, men det ville være en stor brydende ændring.

Ægte overbelastning og generiske stoffer

På mange sprog kan flere versioner af den samme funktion skrives til at arbejde med forskellige slags input. For eksempel entil_streng () -funktionen kunne have forskellige implementeringer til konvertering fra heltal, floating-point-tal eller andre objekter - men de ville dele det samme navn for nemheds skyld. “Overbelastning” eller “generik” gør det lettere at skrive robust software, da du kan skrive generiske metoder til almindelige processer i stedet for at bruge en metode specifikt til en given type.

Python giver dig mulighed for at bruge et funktionsnavn til at arbejde for mange, men ikke ved at definere flere forekomster af en funktion. Du kan kun definere et navn en gang i et givet omfang og binde det til kun et enkelt objekt ad gangen, så du kan ikke have flere versioner af en enkelt funktion under samme navn.

Hvad Python-udviklere typisk gør for at omgå dette, er at bruge indbyggede lignendeisinstance () ellertype() for at bestemme typen af variabel, der sendes til en funktion, og derefter tage handling baseret på typen. Nogle gange indebærer dette afsendelse til en typespecifik version af en funktion under emhætten. Men denne fremgangsmåde gør det svært for andre udviklere at udvide din funktion, medmindre du går ud af din måde at gøre den udvidelig - for eksempel ved at sende til metoder inden for en klasse, som kan underklasseres.

PEP 3124, avanceret i april 2007, foreslog en mekanisme til dekorering af funktioner for at indikere, at de kunne være overbelastede. Forslaget blev udsat snarere end at blive afvist direkte - hvilket betyder, at ideen var grundlæggende sund, men tiden var ikke inde til at gennemføre den. En faktor, der kan fremskynde vedtagelsen af overbelastning i Python - eller få ideen til at blive helt droppet - er implementeringen af det nyligt foreslåede mønstertilpasningssystem.

I teorien kunne mønstermatchning bruges under emhætten til at håndtere overbelastning. Imidlertid kunne mønstermatchning også gives som en begrundelse for ikke implementering af generics i Python, da det allerede giver en elegant måde at sende operationer baseret på typesignaturer.

Så vi kan blive ægte overbelastning i Python en dag, ellers fordeles dens fordele måske af andre mekanismer.

Optimering af halerekursion

Mange sprogkompilatorer anvender optimeringer af tail recursion, hvor funktioner, der kalder sig selv, ikke skaber nye stakrammer i applikationen og dermed risikerer at sprænge stakken, hvis de kører for længe. Python gør ikke dette, og faktisk er dets skabere konsekvent kommet imod det.

En af grundene er, at meget af Python, indefra og ud, brugeriteration hellere endrekursion - generatorer, coroutines og så videre. I dette tilfælde betyder det at bruge en funktion med en løkke og en stakstruktur i stedet for en rekursiv mekanisme. Hvert kald i sløjfen kan gemmes i en stak for at oprette en ny rekursion og springes fra stakken, når rekursionen er færdig.

Python-udviklere opfordres til at bruge disse mønstre i stedet for rekursion, så der ser lidt håb ud til rekursionsoptimeringer. Chancerne her er slet ikke sandsynlige, da Pythons idiomer understøtter andre løsninger.

Multiline lambdas

Lambdas, eller anonyme funktioner, gjorde det kun til Python efter en vis modstand fra sprogskaberen Guido van Rossums side. Da Python-lambdas eksisterer nu, er de meget begrænsede: De giver dig kun mulighed for at bruge et enkelt udtryk (i det væsentlige alt til højre for et ligetegn i en opgaveoperation) som funktionsorgan. Hvis du vil have en fuld blok med udsagn, skal du bare bryde dem ud og lave en faktisk funktion ud fra dem.

Årsagen kommer til sprogets design, som van Rossum ser det. Som van Rossum skrev i 2006, ”finder jegnogen løsning uacceptabel, der integrerer en indrykningsbaseret blok midt i et udtryk. Da jeg finder alternativ syntaks til sætningsgruppering (f.eks. Seler eller start / slut nøgleord) lige så uacceptabel, gør dette stort set en multiline lambda til et uløseligt puslespil. ”

Med andre ord er problemet ikke teknisk, men manglen på en syntaks for multiline lambdas, der supplerer den eksisterende æstetik af Python-syntaks. Der er sandsynligvis ingen måde at gøre det på, der ikke involverer oprettelse af en særlig sag, og et sprog, der tilfalder særlige tilfælde, har tendens til at blive ubehageligt at bruge. Indtil en sådan enhjørning vises, bliver vi bare nødt til at klare os med særskilt definerede funktioner.

Multiline lambdas sker sandsynligvis ikke i Python.