Vēl joprojām trūkst 4 spēcīgu funkciju Python

Python ir dzīva valoda, kas tiek pastāvīgi attīstīta, lai ietu līdzi laikam. Python programmatūras fonds ne tikai veic papildinājumus standarta bibliotēkā un atsauces ieviešanas CPython, bet arī ievieš jaunas funkcijas un uzlabojumus pašā valodā.

Piemēram, Python 3.8 ieviesa jaunu sintaksi rindas uzdevumiem (“valzirgu operators”), kas atsevišķas darbības padara kodolīgākas. Vēl viens nesen apstiprināts sintakses uzlabojums, modeļu saskaņošana, atvieglos koda rakstīšanu, kas novērtē vienu no daudziem iespējamiem gadījumiem. Abas šīs funkcijas iedvesmoja to klātbūtne un lietderība citās valodās.

Un tie ir tikai divi no daudzajiem noderīgajiem līdzekļiem, kurus varētu pievienot Python, lai padarītu valodu izteiksmīgāku, jaudīgāku un piemērotāku mūsdienu programmēšanas pasaulei. Ko vēl mēs varētu vēlēties? Šeit ir vēl četras valodas funkcijas, kas varētu pievienot Pitonam kaut ko reālu vērtību - divus mēs faktiski varētu iegūt, un divus, iespējams, nedarīsim.

Patiesās konstantes

Python patiesībā nav pastāvīgas vērtības jēdziena. Mūsdienās Python konstantes galvenokārt ir konvenciju jautājums. Vārda lietošana ar lielajiem burtiem un čūskas korpusu, piemēram, DO_NOT_RESTART - ir mājiens, ka mainīgais ir paredzēts kā konstante. Līdzīgirakstīt. Visbeidzot tipa anotācija sniedz mājienu, ka objektu nevajadzētu modificēt, taču tas izpildes laikā to nepiespiež.

Kāpēc? Tā kā mainīgums ir dziļi iesakņojies Python uzvedībā. Kad mainīgajam piešķirat vērtību, piemēram,x = 3 - jūs izveidojat vārdu vietējā nosaukumvietā,x, un norādot to uz objektu sistēmā, kuram ir vesela skaitļa vērtība3. Python vienmēr pieņem, ka vārdi ir maināmi - tas ir jebkurš nosaukums varētu norādīt jebkurš objekts. Tas nozīmē, ka katru reizi, kad tiek izmantots nosaukums, Python saskaras ar problēmām, meklējot objektu, uz kuru tas norāda. Šis dinamisms ir viens no galvenajiem iemesliem, kāpēc Python darbojas lēnāk nekā dažas citas valodas. Python dinamisms piedāvā lielu elastību un ērtības, taču tas maksā izpildlaika veiktspēju.

Viena priekšrocība, ka Python ir patiesas nemainīgas deklarācijas, būtu objektu meklēšanas biežuma samazināšana izpildes laikā un tādējādi labāka veiktspēja. Ja izpildlaiks pirms laika zina, ka dotā vērtība nekad nemainās, tai nav jāmeklē tās saistījumi. Tas varētu arī piedāvāt iespēju tālākai trešo pušu optimizācijai, piemēram, sistēmām, kas ģenerē mašīnzemnieku kodu no Python lietotnēm (Cython, Nuitka).

Tomēr patiesās konstantes būtu būtiskas izmaiņas, un, visticamāk, tās būtu nesaderīgas izmaiņas. Būtu arī debates, ja konstantes nāktu ar jaunu sintaksi - piemēram, vēl neizmantoto$ simbols - vai kā Python esošā vārda deklarēšanas veida paplašinājums. Visbeidzot, ir plašāks, filozofisks jautājums par to, vai patiesām konstantēm ir jēga valodā, kurā dinamisms ir bijusi liela apelācijas daļa.

Īsāk sakot, iespējams, ka Python redzēsim patiesas konstantes, taču tās būtu būtiskas pārrāvuma izmaiņas.

Patiesa pārslodze un vispārīgie medikamenti

Daudzās valodās var rakstīt vairākas vienas un tās pašas funkcijas versijas, lai strādātu ar dažāda veida ievadi. Piemēram, ato_string () Funkcijai varētu būt dažādas realizācijas, lai pārveidotu no veseliem skaitļiem, peldošā komata skaitļiem vai citiem objektiem, taču ērtības labad tām būtu tāds pats nosaukums. “Pārslodze” vai “ģenerika” atvieglo stabilas programmatūras rakstīšanu, jo jūs varat rakstīt vispārējas metodes kopīgiem procesiem, nevis izmantot metodi konkrētam tipam.

Python ļauj jums izmantot vienu funkcijas nosaukumu, lai veiktu daudzu darbu, bet ne, nosakot vairākus funkcijas gadījumus. Noteiktajā sfērā vārdu varat definēt tikai vienu reizi un vienlaikus piesaistīt to tikai vienam objektam, tāpēc ar vienu un to pašu nosaukumu nevar būt vairākas vienas funkcijas versijas.

Tas, ko Python izstrādātāji parasti dara, lai apietu šo problēmu, ir līdzīgi iebūvēto ierīču izmantošanaisinstance () vaitips () lai noteiktu funkcijai iesniegtā mainīgā tipu, pēc tam rīkojieties, pamatojoties uz tipu. Dažreiz tas ir saistīts ar funkcijas pārsūtīšanu uz tipam raksturīgu funkcijas versiju zem pārsega. Bet šī pieeja citiem izstrādātājiem apgrūtina jūsu funkcijas paplašināšanu, ja vien jūs nedarāt visu iespējamo, lai padarītu to paplašināmu, piemēram, nosūtot klasē esošās metodes, kuras varētu apakšklasē.

PEP 3124, kas tika izstrādāts 2007. gada aprīlī, piedāvāja funkciju dekorēšanas mehānismu, lai norādītu uz to pārslodzi. Priekšlikums tika atlikts, nevis tika noraidīts tieši - tas nozīmē, ka ideja bija principiāli pamatota, taču laiks nebija piemērots tās īstenošanai. Viens no faktoriem, kas varētu paātrināt pārslodzes pieņemšanu Python vai izraisīt idejas pilnīgu novirzīšanu, ir nesen piedāvātās modeļu saskaņošanas sistēmas ieviešana.

Teorētiski modeļu saskaņošanu varētu izmantot zem pārsega, lai apstrādātu pārslodzes nosūtīšanu. Tomēr modeļa saskaņošanu varētu norādīt arī kā pamatojumu nē ģenerikas ieviešana Python, jo tas jau nodrošina elegantu veidu, kā nosūtīt darbības, pamatojoties uz tipa parakstiem.

Tātad kādu dienu mēs varam iegūt patiesu Python pārslodzi vai arī tās priekšrocības var aizstāt citi mehānismi.

Astes rekursijas optimizācija

Daudzi valodu sastādītāji izmanto astes rekursijas optimizāciju, kur funkcijas, kuras sevi dēvē, lietojumprogrammā nerada jaunus kaudzes rāmjus, un tādējādi pastāv risks, ka kaudze tiks uzspridzināta, ja tās darbosies pārāk ilgi. Python to nedara, un patiesībā tā veidotāji pastāvīgi ir iestājušies pret to.

Viens iemesls ir tas, ka lielu daļu Python izmanto no iekšpuses un ārpusesatkārtojums nevisrekursija - ģeneratori, korutīnas utt. Šajā gadījumā tas nozīmē izmantot funkciju ar cilpu un kaudzes struktūru rekursīvā mehānisma vietā. Katru cilpas izsaukumu var saglabāt kaudzītē, lai izveidotu jaunu rekursiju, un pēc rekursijas pabeigšanas izkrita no kaudzes.

Python izstrādātāji tiek mudināti rekursijas vietā izmantot šos modeļus, tāpēc šķiet maz cerību uz rekursijas optimizāciju. Izredzes šeit vispār nav ticamas, jo Python idiomas atbalsta citus risinājumus.

Daudzrindu lambdas

Lambdas jeb anonīmas funkcijas to padarīja par Python tikai pēc valodas radītāja Gvido van Rosuma zināmas pretestības. Tā kā Python lambdas pastāv jau tagad, tās ir ļoti ierobežotas: tās ļauj izmantot tikai vienu izteiksmi (būtībā visu, kas ir vienādības zīmes labajā pusē piešķiršanas operācijā) kā funkcijas ķermeni. Ja vēlaties pilnu paziņojumu bloku, vienkārši sadaliet tos un izveidojiet no tiem faktisko funkciju.

Iemesls ir saistīts ar valodas dizainu, kā to redz van Rossums. Kā van Rossums rakstīja 2006. gadā, “es uzskatujebkurš nepieņemams risinājums, kas izteiksmes vidū iekļauj bloku, kura pamatā ir ievilkums. Tā kā alternatīvu sintakse paziņojumu grupēšanai (piemēram, bikšturi vai sākuma / beigu atslēgvārdi) man šķiet vienlīdz nepieņemama, tas padara daudzrindu lambda par neatrisināmu mīklu. "

Citiem vārdiem sakot, problēma nav tehniska, bet gan daudzrindu lambdas sintakses trūkums, kas papildinātu esošo Python sintakses estētiku. Iespējams, ka nav veids, kā to izdarīt, nav saistīts ar īpaša gadījuma izveidi, un valoda, kas uzkrāj īpašus gadījumus, mēdz kļūt nepatīkama. Kamēr neparādās šāds vienradzis, mums vienkārši jāiztiek ar atsevišķi definētām funkcijām.

Daudzrindu lambdas, iespējams, nenotiek Python.