Funcții, module și intrare/ieșire

Argumentele poziționale se asociază în ordine, de la stânga, deci a primește 1, iar b primește 3. b are o valoare implicită de 2, dar cum i s-a pasat o valoare, aceasta are prioritate. Valorile care nu au mai putut fi asociate, 4 și 5, sunt grupate ca tuplu în args, cel cu un singur asterisc, devenind (4, 5). Nu s-a pasat niciun argument cu nume, deci kwargs este dicționarul gol {}, nu None. Dacă s-ar crede că b păstrează valoarea implicită 2, s-ar ajunge la (1, 2, (3, 4, 5), {}), dar argumentele poziționale au prioritate față de valorile implicite. În args ajunge un tuplu, nu o listă, deci nu apare afișat cu paranteze pătrate.

Există un singur argument pozițional, deci a primește 1, iar cum b nu a fost pasat, rămâne la valoarea implicită 2. Parametrul cu numele x nu există în definiție, deci argumentul cu cuvânt-cheie x=9 ajunge în kwargs, cel cu doi asteriscuri, ca {'x': 9}. Nu au rămas argumente poziționale în plus, deci args este tuplul gol (). Dacă s-ar crede că x=9 ajunge în b, s-ar obține (1, 9, (), {}), dar un argument cu nume ajunge doar la parametrul al cărui nume se potrivește. Dacă s-ar crede că 9 ajunge în args, s-ar obține (1, 2, (9,), {}), dar o valoare pasată cu nume nu se transformă în argument pozițional în exces. Dacă se confundă rolul celor doi asteriscuri, crezând că unul primește dicționarul și celălalt tuplul, s-ar putea vedea eronat {'x': 9} în args și kwargs gol.

Valoarea implicită [] este creată o singură dată, la execuția liniei def, iar acea aceeași listă rămâne salvată în obiectul funcției. Nu se creează o listă vidă nouă la fiecare apel, deci rezultatele lui append rămân de la un apel la altul, iar lista crește: [1], [1, 2], [1, 2, 3]. Dacă s-ar crede că fiecare apel primește o listă nouă, s-ar obține [1] / [2] / [3], dar acesta ar fi comportamentul dacă lst=None ar fi valoarea implicită, iar lista s-ar recrea în corpul funcției. Dacă corpul ar fi scris greșit ca return lst.append(x), ar apărea de trei ori None, valoarea returnată de append. De notat că, scris pe o singură linie, print(add(1), add(2), add(3)), toate cele trei apeluri indică aceeași listă, deci se afișează de trei ori [1, 2, 3], forma finală după ce toate evaluările s-au încheiat.

Obiectul funcției păstrează valorile implicite ca tuplu, în atributul __defaults__. Dintre parametri, doar lst are valoare implicită, deci devine un tuplu cu un singur element, afișat cu virgulă la sfârșit. Conținutul acelui element este chiar lista creată o singură dată la linia def, iar rezultatul celor 3 append-uri din apeluri rămâne acolo, deci devine ([1, 2, 3],). Dacă nu s-ar fi apelat funcția deloc, ar fi ([],), dar faptul că apelurile își lasă urma aici este exact pericolul unui argument implicit mutabil. __defaults__ însuși este tuplu, deci nu se afișează cu paranteze pătrate, iar lista din interior nu devine tuplu.

Expresia unei valori implicite nu se evaluează la fiecare apel al funcției, ci o singură dată, în momentul în care se execută linia def. La acel moment, i este 5, deci 5 este salvat în obiectul funcției. Chiar dacă i este ulterior schimbat în 10, valoarea implicită deja salvată nu se schimbă, deci h() returnează 5. Pe de altă parte, h(i) citește i chiar în momentul apelului și îl pasează, deci returnează valoarea curentă, 10. Dacă s-ar crede că valoarea implicită se evaluează la fiecare apel, ambele linii ar deveni 10; dacă s-ar crede că și valoarea pasată se înlocuiește cu cea implicită, ambele linii ar deveni 5. Și capcana argumentului implicit mutabil provine din aceeași regulă.

Nu este permis ca, după un parametru cu valoare implicită, să urmeze un parametru fără valoare implicită. Această regulă este verificată la nivel sintactic, deci, la rularea fișierului, apare mai întâi SyntaxError, cu mesajul non-default argument follows default argument. Analiza sintactică se face pentru întregul fișier înainte de execuție, deci nici măcar linia cu print nu se execută. Este un moment de detecție complet diferit de un TypeError cauzat de un apel greșit. Apelul g(2, 3) ar corespunde ca număr de parametri, deci dacă definiția ar fi corectă, ar apărea 5, dar execuția nu ajunge până acolo. Forma corectă este să se pună parametrul cu valoare implicită la urmă, ca în def g(b, a=1).

one se termină fără să treacă niciodată printr-un return, deci valoarea returnată este None. Nu se returnează nici un tuplu gol, nici un șir vid. two are după return valorile 1 și 2, separate prin virgulă, dar acestea nu reprezintă returnarea a două valori, ci returnarea unui singur tuplu, (1, 2). Prin urmare, type(two()).__name__ este tuple. Dacă s-ar crede că valorile multiple se strâng într-o listă, ar rezulta list, dar o expresie cu virgule formează un tuplu. Blocajele apărute la folosirea valorii returnate de o funcție care doar afișează sunt, de multe ori, cauzate exact de acest None.

Dacă la apel se pune un singur asterisc înaintea unei liste, conținutul ei este distribuit ca argumente poziționale, unul câte unul. Astfel, a primește 1, b primește 2, iar 3, rămas în plus, este grupat ca tuplu în args, cel cu un asterisc, devenind (3,). Fiind un tuplu cu un singur element, apare cu virgulă la sfârșit. Nu s-au pasat argumente cu nume, deci kwargs este dicționarul gol {}, nu None. Dacă se uită asteriscul și se scrie f(vals), lista în sine ajunge la primul parametru, rezultând ([1, 2, 3], 2, (), {}) — nu apare nicio eroare, dar rezultatul se schimbă complet. În args ajunge un tuplu, deci nu apare afișat cu paranteze pătrate.

Adnotările sunt doar înregistrate în dicționarul __annotations__ al obiectului funcției; tipul nu este verificat la execuție. Deși a este adnotat cu int, i se poate pasa un șir de caractere; deși b este adnotat cu str, i se poate pasa un întreg. Deși valoarea returnată este adnotată cu bool, ceea ce se returnează efectiv este exact șirul de caractere primit. Prin urmare, pe prima linie apare direct șir de caractere. Ceea ce se află în __annotations__['a'] de pe a doua linie este obiectul de tip int, deci afișat cu print apare sub forma <class 'int'>. Nu apar doar cele 3 litere int. Pentru a verifica efectiv tipurile, e nevoie de un instrument dedicat de verificare, sau de o verificare scrisă manual în corpul funcției.

Practica standard este să se folosească None ca valoare implicită, iar la începutul corpului să se verifice dacă este None, creând atunci o listă nouă și vidă. None este o valoare care nu se poate modifica, deci, chiar dacă e evaluat o singură dată, nu apare problema partajării. La primul și al doilea apel, unde lst este omis, se creează de fiecare dată câte o listă nouă și vidă, deci rezultă [1] și [2], fără ca elementele apelului anterior să rămână. La al treilea apel, apelantul pasează [9], deci lst is None devine fals, iar 3 se adaugă la sfârșitul listei primite, rezultând [9, 3]. Dacă s-ar fi păstrat lst=[] fără rescriere, la al doilea apel, unde argumentul e omis, ar rămâne elementul apelului anterior, rezultând [1, 2]. Dacă s-ar ignora lista pasată de apelant și s-ar crea mereu o listă nouă, ar rezulta [1] / [2] / [3], pierzându-se tocmai avantajul acestei practici, „dacă se pasează ceva, se folosește acel ceva”. Dacă în loc de append, care adaugă la sfârșit, s-ar folosi insert(0, x), care inserează la început, al treilea apel ar deveni [3, 9].

LEGB este acronimul de la Local, Enclosing, Global, Built-in și indică o căutare de la cel mai interior nivel spre exterior. Se caută mai întâi în interiorul funcției în execuție, apoi în funcția exterioară care o cuprinde, apoi la nivelul de vârf al modulului și, în cele din urmă, printre numele predefinite precum len sau print. Căutarea se oprește de îndată ce este găsit ceva, deci, dacă interiorul folosește același nume, numele exterior este ascuns. Dacă ordinea ar fi de la exterior spre interior, o variabilă locală creată în interiorul funcției ar fi învinsă de o variabilă cu același nume de la nivelul de vârf al modulului, ceea ce nu corespunde comportamentului real. O greșeală frecventă este inversarea ordinii Global și Enclosing, dar funcția exterioară este mai interioară decât nivelul de vârf al modulului.

O atribuire făcută la un nume în interiorul unei funcții creează o variabilă locală nouă cu acel nume, fără să afecteze deloc variabila cu același nume de la nivelul de vârf al modulului. print(x) din interiorul funcției citește x-ul local, deci afișează local, dar print(x) de după ieșirea din funcție citește x-ul de la nivelul de vârf al modulului, deci afișează global. Dacă s-ar crede că atribuirea din interiorul funcției ajunge și în exterior, ambele linii ar deveni local, dar pentru asta ar fi necesar să se declare global x la începutul funcției. Invers, dacă s-ar crede că atribuirea din interior este ignorată și se citește tot valoarea din exterior, ambele linii ar deveni global, dar, odată făcută atribuirea, variabila locală chiar există. Această asimetrie — citirea ajunge până în exterior, dar scrierea nu — este de bază pentru domeniul de vizibilitate din Python.

Funcția inner din outer are scris nonlocal n, deci o atribuire la n ajunge la n-ul funcției exterioare imediate, outer. După apelul lui inner, n-ul returnat de outer devine 2. Funcția inner din outer2 nu are declarația, deci n = 2 doar creează o variabilă locală nouă în inner, iar n-ul lui outer2 rămâne neschimbat, 1. Prin urmare, se afișează 2 1. Dacă s-ar crede că ambele modificări ajung în exterior, s-ar afișa 2 2; dacă s-ar crede că niciuna nu ajunge, s-ar afișa 1 1, dar diferența este produsă exact de acea singură linie cu nonlocal. De notat că nonlocal nu poate fi folosit dacă în funcția exterioară nu există deja o variabilă cu același nume, și nici nu poate indica o variabilă de la nivelul de vârf al modulului. Pentru a modifica o variabilă de la nivelul de vârf, se folosește global.

Python decide, chiar la compilarea corpului unei funcții, că orice nume care are o atribuire în acea funcție este variabilă locală. Această decizie se ia pentru întreaga funcție, indiferent de ordinea rândurilor. În funcția bad, cum există o atribuire z = 1 pe un rând ulterior, z este tratat ca variabilă locală a acestei funcții. Prin urmare, la momentul print(z) nu există încă nicio valoare atribuită, deci apare UnboundLocalError. Formularea exactă a mesajului acestei excepții diferă în funcție de versiunea Python, dar numele tipului rămâne UnboundLocalError. Chiar dacă există un z = 100 la nivelul de vârf, acesta nu este referit. Dacă s-ar crede că, fiind înainte de atribuire, se citește exteriorul, ar rezulta 100, dar Python nu funcționează astfel. Nici o variabilă locală fără valoare nu devine None.

f are scris global n, deci n = 20 modifică n-ul de la nivelul de vârf al modulului. f însuși returnează 20, iar n-ul de la nivelul de vârf devine și el 20. g nu are declarația, deci n = 30 doar creează o variabilă locală în g, fără să afecteze n-ul de la nivelul de vârf. g returnează propriul său n local, 30. n-ul citit de ultimul print este cel de la nivelul de vârf, care, după modificarea făcută de f, este 20. Dacă s-ar crede că și atribuirea din g ajunge în exterior, s-ar obține 20 30 30; dacă s-ar crede că global nu are efect, s-ar obține 20 30 10. Trebuie reținut și că declarația global este o instrucțiune care spune „această atribuire să ajungă la nivelul de vârf” — pentru simpla citire, declarația nu este necesară.

Importul cu asterisc aduce, în mod normal, toate numele care nu încep cu underscore, dar dacă în modul există o listă de șiruri numită __all__, se aduc doar numele enumerate acolo. În acest exemplu, __all__ conține doar pub, deci nici other, nici hello nu sunt aduse. other nu începe cu underscore, dar, câtă vreme __all__ există, lista sa are prioritate. Nu există niciun tratament special pentru funcții, deci nici hello nu este adus. __all__ are efect doar la importul cu asterisc — importul explicit al unui nume, ca în from mymod import hello, sau folosirea sub forma import mymod urmată de mymod.hello(), nu sunt afectate.

Atunci când fișierul este rulat direct cu python3, __name__ primește valoarea '__main__'. Atunci când este importat dintr-un alt fișier, primește numele fișierului fără extensie, 'mymod2'. Prin urmare, la rulare directă apar cele 2 rânduri mymod2: __main__ și rulare directă, iar la import apare doar un singur rând, mymod2: mymod2. Construcția if __name__ == '__main__': folosește exact această diferență pentru a separa, în mod standard, „procesarea care trebuie rulată doar la execuția directă”. Dacă cele două s-ar inversa, la import ar rula procesarea de verificare gândită pentru rularea directă, ceea ce ar contrazice scopul acestei construcții. Dacă în ambele cazuri valoarea ar fi identică, nu ar mai fi posibilă deloc această separare.

sys.argv este o listă cu valorile pasate din linia de comandă, iar la începutul ei se află chiar numele scriptului. În acest exemplu devine o listă cu 3 elemente, precum ['args.py', 'foo', 'bar'], deci len este 3. sys.argv[1:], care extrage de la indexul 1 în sus, devine ['foo', 'bar'], fără numele scriptului. Dacă s-ar crede că lungimea este direct numărul de argumente pasate, s-ar obține 2, uitându-se de numărat numele scriptului de la început. A crede că sys.argv[1:] devine ['args.py', 'foo'] corespunde unei confundări a poziției de start a feliei. Rulat fără niciun argument, lungimea este 1, iar sys.argv[1:] este o listă vidă.

Un modul, odată încărcat, este păstrat în cache în dicționarul sys.modules. Al doilea import doar leagă din nou numele de același obiect de modul, deja înregistrat acolo, deci nu are loc nici recitirea fișierului, nici reexecutarea corpului. Se poate confirma acest lucru punând un print la nivelul de vârf al modulului: chiar dacă este importat de două ori, apare o singură dată. Chiar dacă importul se face sub un alt nume, se indică tot același obiect. Prin urmare, dacă se modifică o variabilă a unui modul, valoarea modificată se vede și din alte locuri care importă acel modul. Importul aceluiași nume de două ori nu produce eroare; dacă se dorește, în timpul dezvoltării, o recitire efectivă a corpului, trebuie folosite explicit funcțiile din importlib.

sys.prefix indică locul unde este instalat Python-ul care rulează acum, iar sys.base_prefix indică locul Python-ului original din care provine. În afara unui mediu virtual, ambele au aceeași valoare, dar în interiorul unui mediu creat cu python3 -m venv, sys.prefix indică directorul mediului creat, în timp ce sys.base_prefix continuă să indice Python-ul original, deci cele două diferă. Prezența sau absența acestei diferențe este indiciul folosit pentru determinare. Ideea că, dacă coincid, s-ar afla într-un mediu virtual, este condiția inversă. sys.base_prefix este întotdeauna definit, chiar și în afara unui mediu virtual, deci prezența sau absența definirii nu poate servi la determinare. La fel, sys.prefix este întotdeauna definit. Calea concretă sau versiunea lui pip diferă de la un mediu la altul, deci este suficient să se rețină doar această relație.

write returnează numărul de caractere scrise. "one\ntwo\nthree\n" are one cu 3 caractere, two cu 3 caractere, three cu 5 caractere, adică 11 în total, plus cele 3 caractere de linie nouă, deci 14 în total. Dacă se uită de numărat liniile noi, rezultă 11. Dacă s-ar crede că se returnează numărul de linii scrise, ar rezulta 3, dar ceea ce numără write este strict numărul de caractere. A alege None, crezând că nu se returnează nimic, este de asemenea o greșeală frecventă, ușor de confundat cu metode precum append sau sort, care returnează None, dar write returnează un număr. De notat că write nu adaugă automat un caracter de linie nouă, deci, dacă se dorește separarea liniilor, acesta trebuie scris explicit în șirul de caractere.

readlines returnează toate liniile ca listă, dar caracterul de linie nouă de la sfârșitul fiecărui element rămâne. Prin urmare, rezultă ['one\n', 'two\n', 'three\n']. Dacă s-ar crede că liniile noi sunt eliminate, s-ar obține ['one', 'two', 'three'], dar pentru asta ar trebui aplicat rstrip pe fiecare element. Ceea ce returnează un singur șir de caractere, fără să separe pe linii, este read; readlines returnează o listă. Dacă s-ar crede că nu se tratează linia nouă drept separator, ci se împachetează întregul fișier ca un singur element, s-ar obține ['one\ntwo\nthree\n'], dar readlines separă elementele la fiecare linie nouă. Și atunci când se scrie for line in f, pentru a extrage linie cu linie, linia primită are, la fel, linia nouă atașată.

Un obiect fișier își memorează poziția curentă. Primul read citește complet de la început până la sfârșit, deci a primește cele 14 caractere, inclusiv linia nouă, iar poziția se mută la sfârșit. Al doilea read încearcă să citească pornind de la sfârșit, deci nu mai rămâne nimic, iar rezultatul este un șir vid. Prin urmare, len(a) este 14, iar b == '' este True. Dacă s-ar crede că și a doua citire returnează același conținut, b == '' ar deveni False, dar pentru a reciti același conținut este nevoie de f.seek(0), care readuce poziția la început. len(a) devine 0 doar dacă fișierul era gol sau poziția era deja la sfârșit. Este o situație ușor de interpretat greșit ca eșec al citirii, dar cauza este că poziția se afla la sfârșit.

În interiorul blocului with, fișierul este încă deschis, deci closed este False. La ieșirea din bloc, fișierul se închide automat, deci closed devine True imediat după aceea. Prin urmare, se afișează False, apoi True. Scopul folosirii lui with este să se asigure că închiderea are loc chiar dacă cineva uită să scrie acest cod, inclusiv atunci când apare o excepție în interiorul blocului și se iese pe neașteptate. Separând prin virgulă, se pot deschide mai multe fișiere într-un singur with, iar toate sunt închise la fel. Încercarea de a citi dintr-un obiect fișier deja închis produce ValueError, deci nu se mai poate reciti în afara blocului with.

Deschis cu 'w', fișierul este trunchiat la lungime 0 în acel moment, indiferent de conținutul existent anterior. Urmărind pas cu pas: prima deschidere cu 'w' scrie AAA, apoi deschiderea cu 'a', fiind adăugare, produce AAABBB. Însă, în momentul în care se deschide a treia oară cu 'w', AAABBB dispare, iar C este scris acolo, deci la final rămâne doar C. Dacă s-ar crede că toate cele 3 deschideri s-au făcut cu 'a', ar rezulta AAABBBC; dacă s-ar crede că ultima scriere a fost ignorată, ar rezulta AAABBB. Suprascrierea de la început, fără trunchiere, este comportamentul lui 'r+', caz în care s-ar înlocui doar primul caracter, rezultând CAABBB. Trunchierea are loc chiar în momentul deschiderii, nu al scrierii, deci, dacă se deschide cu 'w' și nu se scrie nimic, fișierul rămâne gol. Pentru a adăuga la conținut se folosește 'a', iar pentru a-l reface complet, 'w' — intenția se exprimă prin mod.

Apelarea lui read pe un obiect fișier deja închis produce ValueError, cu mesajul I/O operation on closed file. Faptul că fișierul a fost închis este memorat de obiect, deci nu are loc o redeschidere automată doar pentru că e nevoie de conținut. Nu se returnează nici un șir vid în sensul „nu mai e nimic de citit” — acesta este comportamentul lui read după ce s-a citit complet până la sfârșit. FileNotFoundError, care apare când fișierul nu este găsit, face parte din familia OSError, dar excepția produsă la operarea pe un fișier închis este alta, ValueError. Folosind instrucțiunea with, se evită structural chiar și posibilitatea de a încerca să se citească după ieșirea din bloc.

Dacă al doilea argument al lui open este omis, se folosește implicit modul de citire 'r'. Apelarea lui write pe un obiect fișier deschis doar pentru citire produce io.UnsupportedOperation, cu mesajul not writable. Fiind o construcție sintactic corectă, eroarea de mod devine vizibilă abia la rulare. Pentru a suprascrie se folosește 'w', pentru a adăuga la sfârșit 'a', iar pentru citire și scriere combinate, redeschiderea cu 'r+'. Invers, apelarea lui read pe un fișier deschis cu 'w' sau 'a' produce, la fel, io.UnsupportedOperation, dar cu mesajul not readable. Se poate spune că modul este locul unde se declară ce este permis pentru acel obiect fișier.

Dacă i se pasează un număr lui read, se citește doar atâtea caractere. Primele 5 caractere sunt cele 3 din one, linia nouă, și t din two, deci rezultă 'one\nt'. Poziția avansează cu atâtea caractere cât s-a citit, deci tell-ul imediat următor returnează 5. Cu seek(0), care urmează, poziția revine la început, deci ultimul tell returnează 0. Dacă s-ar crede că read nu modifică poziția, ambele apeluri tell ar returna 0; dacă s-ar crede că seek nu are efect, ambele ar returna 5. Dacă argumentul lui read este confundat cu numărul de linii în loc de numărul de caractere, s-ar putea alege greșit forma cu întregul fișier 'one\ntwo\nthree\n' și 14, gândindu-se că se citesc primele 5 linii. Folosind seek(0) se poate reciti de la început, din același obiect fișier.

În JSON există doar tablouri (array), nu și tipul tuplu. De aceea, la momentul dumps, un tuplu este convertit la tablou, iar rezultatul este {"t": [1, 2]}. La citirea înapoi, tabloul este reconstituit ca listă, deci tipul lui back['t'] este list, nu revine la tuplu. Nicăieri nu rămâne informația că originalul era un tuplu, deci un ciclu dus-întors schimbă tipul. Dacă se dorește păstrarea ca tuplu, trebuie aplicat manual tuple() după citirea înapoi. În ieșirea JSON nu apar niciodată paranteze rotunde, iar tuplul nu se transformă în șir de caractere. Din același motiv, dacă se folosește un întreg drept cheie în dicționar, dumps îl convertește la șir de caractere, iar la citirea înapoi nu revine la întreg.

Cheile unui obiect JSON trebuie să fie șiruri de caractere, deci, la dumps pe un dicționar cu cheie întreagă, cheia este convertită la șir, iar rezultatul afișat este {"1": "a"}. Aceasta este o operație care reușește normal, fără să producă excepție aici. Trebuie observat totuși că, la citirea înapoi, cheia rămâne șir de caractere, fără să revină la întreg. Mulțimea de pe a doua linie nu are un tip corespunzător în JSON, deci încercarea de a face dumps produce TypeError, cu mesajul Object of type set is not JSON serializable. Dacă s-ar crede că mulțimea se scrie ca tablou, s-ar obține [1, 2], dar pentru a obține acea conversie trebuie aplicat manual list() înainte de a pasa valoarea. Pentru valorile care conțin caractere japoneze, implicit acestea sunt scrise cu escapare, iar pasând fals la ensure_ascii, sunt scrise direct, cu caracterele originale.