4 zmogljive funkcije Python še vedno manjka

Python je živ jezik - v nenehnem razvoju, da bi bil v koraku s časom. Fundacija programske opreme Python ne dodaja samo standardne knjižnice in referenčne izvedbe CPython, temveč tudi uvaja nove funkcije in izboljšave samega jezika.

Na primer, Python 3.8 je uvedel novo sintakso za vrstne dodelitve (»operater mrožev«), zaradi katere so nekatere operacije bolj jedrnate. Drugo novo odobreno izboljšanje skladnje, ujemanje vzorcev, bo olajšalo pisanje kode, ki oceni enega od številnih možnih primerov. Obe funkciji sta bili navdihnjeni s svojo prisotnostjo in uporabnostjo v drugih jezikih.

In le dve izmed številnih uporabnih funkcij, ki bi jih lahko dodali Pythonu, da bi bil jezik bolj izrazit, zmogljivejši in bolj primeren sodobnemu programskemu svetu. Kaj bi si še lahko želeli? Tu so še štiri jezikovne funkcije, ki bi Pythonu lahko dodale nekaj resnične vrednosti - dve bomo morda dejansko dobili, dve pa verjetno ne.

Resnične konstante

Python v resnici nima koncepta konstantne vrednosti. Danes so konstante v Pythonu večinoma dogovor. Uporaba imena, ki je v velikih črkah in kačah - npr. DO_NOT_RESTART - je namig, da naj bi bila spremenljivka konstanta. Podobno jetipkanje.Končno pripis tipa daje namig povezovalcem, da predmeta ne bi smeli spreminjati, vendar tega med izvajanjem ne uveljavlja.

Zakaj? Ker je mutabilnost globoko zakoreninjena v Pythonovem vedenju. Ko spremenljivki dodelite vrednost - npr.x = 3 - ustvarjate ime v lokalnem imenskem prostoru,xin ga usmeril na objekt v sistemu, ki ima celoštevilčno vrednost3. Python ves čas domneva, da so imena spremenljiva - to kaj ime bi lahko kazalo na kaj predmet. To pomeni, da se Python vsakič, ko uporabimo ime, potrudimo, da poiščemo, na kateri predmet kaže. Ta dinamičnost je eden glavnih razlogov, zakaj Python deluje počasneje kot nekateri drugi jeziki. Pythonova dinamičnost ponuja veliko fleksibilnost in udobje, vendar gre za ceno zmogljivosti izvajanja.

Ena od prednosti resničnih konstantnih deklaracij v Pythonu bi bilo nekaj zmanjšanja pogostosti iskanja predmetov, ki se zgodijo med izvajanjem, in s tem boljša zmogljivost. Če izvajalno okolje pred časom ve, da se določena vrednost nikoli ne spremeni, mu ni treba iskati svojih vezi. To bi lahko zagotovilo tudi pot za nadaljnje optimizacije tretjih oseb, na primer sisteme, ki iz Pythonovih aplikacij (Cython, Nuitka) generirajo strojno izvorno kodo.

Resnične konstante bi bile velika sprememba in najverjetneje nezdružljiva sprememba. Prav tako bi bilo treba razpravljati, če bi konstante prišle z novo skladnjo - na primer še neuporabljena$ simbol - ali kot razširitev obstoječega Pythonovega načina prijave imen. Na koncu je še širše, filozofsko vprašanje, ali so resnične konstante smiselne v jeziku, kjer je bila dinamika velik del privlačnosti.

Skratka, mogoče je, da bomo v Pythonu videli prave konstante, vendar bi bila to velika prelomna sprememba.

Resnično preobremenitev in generiki

V mnogih jezikih je mogoče napisati več različic iste funkcije za delo z različnimi vrstami vnosa. Na primer, ato_string () funkcija bi lahko imela različne izvedbe za pretvorbo iz celih števil, števil s plavajočo vejico ali drugih predmetov - vendar bi si zaradi udobja delila isto ime. »Preobremenitev« ali »generiki« olajšata pisanje robustne programske opreme, saj lahko za običajne procese napišete splošne metode, namesto da bi uporabili metodo posebej za določeno vrsto.

Python vam omogoča, da z enim imenom funkcije opravite delo mnogih, vendar ne z definiranjem več primerkov funkcije. Ime lahko v določenem obsegu definirate samo enkrat in ga hkrati povežete samo z enim predmetom, zato ne morete imeti več različic ene same funkcije pod istim imenom.

Razvijalci Pythona navadno naredijo to, da to rešijo, je uporaba vgrajenih datotekisinstance () alivrsta () da določite vrsto spremenljivke, ki je bila poslana funkciji, nato pa ukrepajte glede na vrsto. Včasih to vključuje odpošiljanje na specifično različico funkcije pod pokrovom. Toda ta pristop drugim razvijalcem otežuje razširitev vaše funkcije, razen če se potrudite, da jo naredite razširljivo - na primer z razpošiljanjem na metode znotraj razreda, ki bi jih lahko razvrstili v podrazred.

PEP 3124, izpopolnjen aprila 2007, je predlagal mehanizem za okrasitev funkcij, ki kaže, da bi lahko bile preobremenjene. Predlog je bil odložen, namesto da bi bil popolnoma zavrnjen - kar pomeni, da je bila ideja v osnovi trdna, vendar čas ni bil primeren za njeno izvedbo. Eden od dejavnikov, ki bi lahko pospešil sprejetje preobremenitve v Pythonu - ali povzroči, da se ideja popolnoma odpove, je izvajanje novega predlaganega sistema za ujemanje vzorcev.

Teoretično bi lahko pod pokrovom uporabili ujemanje vzorcev za obdelavo preobremenitve. Vendar pa bi lahko bilo tudi obrazložitev ujemanja vzorcev ne izvajanje generikov v Pythonu, saj že ponuja eleganten način pošiljanja operacij na podlagi podpisov tipov.

Tako bomo lahko nekega dne resnično preobremenjeni v Pythonu ali pa bodo njegove prednosti nadomeščeni z drugimi mehanizmi.

Optimizacije rekurzije repa

Številni jezikovni prevajalniki uporabljajo optimizacije rekurzije repa, kjer funkcije, ki se same pokličejo, v aplikaciji ne ustvarijo novih okvirov skladov in s tem tvegajo razstrelitev sklada, če delujejo predolgo. Python tega ne počne in pravzaprav so njegovi ustvarjalci dosledno nasprotovali temu.

Eden od razlogov je, da velik del Pythona uporablja od znotraj navzvenponovitev raje kotrekurzija - generatorji, podprogrami itd. V tem primeru pomeni uporabo funkcije z zanko in strukturo skladov namesto rekurzivnega mehanizma. Vsak klic zanke lahko shranite v sklad, da ustvarite novo rekurzijo, in ga izklopite, ko se rekurzija konča.

Razvijalce Pythona spodbujamo, naj te vzorce uporabljajo namesto rekurzije, zato se zdi malo upanja za optimizacije rekurzije. Tu možnosti sploh niso verjetne, saj Pythonovi idiomi podpirajo druge rešitve.

Večvrstne lambde

Lambde ali anonimne funkcije so v Python prišle šele po nekaj odporu s strani ustvarjalca jezika Guida van Rossuma. Ker lambde Python obstajajo zdaj, so zelo omejene: dovoljujejo vam, da kot telo funkcije uporabite samo en izraz (v bistvu kar koli na desni strani znaka enakosti v operaciji dodelitve). Če želite celoten blok stavkov, jih preprosto razdelite in iz njih ustvarite dejansko funkcijo.

Razlog za to je oblikovanje jezika, kot ga vidi van Rossum. Kot je van Rossum zapisal leta 2006, »ugotavljamkaj nesprejemljiva rešitev, ki sredi izraza vdela blok, ki temelji na zamikih. Ker se mi zdi enaka nesprejemljiva tudi sintaksa za razvrščanje stavkov (npr. Oklepaje ali ključne besede za začetek / konec), zaradi česar je večvrstna lambda nerešljiva uganka. "

Z drugimi besedami, težava ni tehnična, ampak pomanjkanje sintakse za večvrstične lambde, ki dopolnjuje obstoječo estetiko sintakse Python. Verjetno tega ni mogoče storiti, da ne bi bilo treba ustvariti posebnega primera, jezik, ki nabira posebne primere, pa postane neprijeten za uporabo. Dokler se takšen samorog ne pojavi, se bomo morali samo zadovoljiti z ločeno določenimi funkcijami.

Večvrstne lambde se v Pythonu verjetno ne dogajajo.