Bun venit la lecția unu a cursului Python Fundamentals. Șaizeci de lecții, două pe săptămână, publicate marțea și vinerea de acum până în iunie. La final vei fi scris o cantitate decentă de Python, îl vei fi spart în moduri interesante, îl vei fi reparat, vei fi învățat povestea testării și a packaging-ului și vei fi parcurs destul din ecosistem cât cuvintele pyproject.toml, pytest, pyright, asyncio și uv să-ți pară prieteni vechi, nu thumbnail-uri de YouTube.
Nu este un curs „învață să scrii cod de la zero”. Presupune că ai mai scris ceva într-un anume limbaj înainte: poate JavaScript la facultate, poate puțin bash la serviciu, poate un job SQL care a căpătat un „If”, apoi un regex și într-o zi a devenit un program. Dacă n-ai scris niciodată cod, poți totuși să urmărești cursul, dar așteaptă-te să petreci timp pe lângă el completând concepte de bază (variabile, bucle, funcții) la care nu ne vom opri. La ce ne vom opri: cum se scrie Python așa cum se scrie efectiv Python modern în 2026, ceea ce e semnificativ diferit față de cum se scria chiar și acum cinci ani.
Înainte să atingem cod, să cartografiem terenul. Ce este Python în 2026, ce versiune ar trebui să instalezi efectiv și care dintre schimbările din ultimii șase ani contează într-o zi normală la birou?
Starea limbajului, mai 2026
Python 3.13 este versiunea stabilă curentă. A apărut în octombrie 2024 și e ținta aproape oricărui tutorial recent, biblioteci și imagini Docker de bază. Python 3.14 este în dezvoltare și programat pentru octombrie 2026, cu beta-urile obișnuite pe parcursul verii. Până când se termină acest curs, vei vedea aterizând primele release candidates pentru 3.14. Pe parcursul cursului vom ținti 3.13; nimic din ce facem nu se va sparge pe 3.14.
Python 2 a murit în 2020. Dacă cineva îți spune că „mai scrie un pic de Python 2”, dă din cap înțelegător și mergi mai departe. S-a dus. Migrarea s-a încheiat. Șase ani de doliu post-funeralii sunt suficienți.
Python 3.0 până la 3.7 sunt și ele depreciate și nesuportate. Dacă te trezești pe un sistem care livrează 3.6 sau 3.7, faci arheologie de mentenanță și ar trebui să începi prin a-ți da seama cum să instalezi un interpretor modern în paralel, fără să spargi Python-ul de sistem. (Tratăm exact asta în lecția 4.)
Python 3.8 până la 3.12 sunt încă foarte prezente. 3.10 și 3.11 în special sunt peste tot: Ubuntu 22.04 LTS a livrat 3.10, Ubuntu 24.04 LTS a livrat 3.12, iar multe laptop-uri de companie sunt încă pe ce le-a dat sistemul de operare. Trebuie să știi că sintaxa pe care o vom folosi țintește 3.10 ca minim realist. Mai vechi și va trebui să rescrii câteva exemple.
Așadar: instalează 3.13, scrie cod care rulează pe 3.10+, nu te pierde cu somnul peste versiuni mai vechi decât dacă te obligă jobul.
Ce s-a schimbat și merită știut
Șase ani de release-uri Python, distilate în lucrurile care chiar au schimbat felul în care se scrie Python la lucru.
Pattern matching (3.10). Instrucțiunea match / case. Arată ca un switch din limbajele familiei C, dar e semnificativ mai puternic: destructurează, face match pe tipuri și forme și se integrează cu dataclasses și named tuples. Unii îl folosesc excesiv; alții se prefac că nu există. Ambele tabere greșesc. Îl tratăm cum se cuvine în lecția 3.
Operatorul | pentru uniunea de tipuri (3.10). Înainte scriai Optional[int] sau Union[int, str]. Acum e int | None și int | str. Mai curat, fără import. Type checker-ele îl adoră. Folosește-l. Lecția 2 intră în detalii.
Mesaje de eroare mai bune (3.11). Traceback-ul indică acum exact subexpresia care a explodat, nu doar linia. Dacă te-ai uitat vreodată la un KeyError pe o linie cu cinci dictionary lookups, întrebându-te care dintre ele e vinovatul, această singură schimbare îți economisește ore pe lună. E discretă, e gratuită, pur și simplu funcționează.
CPython mai rapid (3.11+). Proiectul „Faster CPython” condus de Guido și Mark Shannon a livrat un lot de accelerări de interpretor în 3.11, mai multe în 3.12 și un compilator JIT opt-in în 3.13. Workload-urile reale văd de obicei accelerări de 10-25% trecând de la 3.10 la 3.13, fără modificări de cod. JIT-ul din 3.13 este opt-in și experimental: îl construiești cu --enable-experimental-jit și-l benchmarkezi înainte să te bazezi pe el în producție. Până în 3.15 va fi probabil implicit, iar toți vom uita că s-a făcut tranziția.
Sintaxă nouă pentru typing (3.12). PEP 695 a introdus o cale mai curată de a declara generic types și type aliases:
# Vechi (încă funcționează)
from typing import TypeVar
T = TypeVar("T")
def first(items: list[T]) -> T:
return items[0]
# Nou, 3.12+
def first[T](items: list[T]) -> T:
return items[0]
type Json = dict[str, "Json"] | list["Json"] | str | int | float | bool | NoneCea mai mare parte a ecosistemului a trecut deja la asta. O folosim de la lecția 2 încolo.
Build free-threaded (3.13, experimental). Asta e cea mare în plan abstract: un build de Python fără Global Interpreter Lock. GIL-ul este lock-ul care a împiedicat paralelismul real în cod pur Python din 1992. PEP 703 a fost aprobat, iar 3.13 livrează un build free-threaded opțional (python3.13t). Chiar acum, în mai 2026, e încă experimental, bibliotecile sunt încă auditate pentru thread-safety și nu ar trebui să rulezi workload-uri de producție pe el decât dacă ai măsurat cu mare grijă. Dar funcționează, e real și se va muta din experimental în stabil pe parcursul următoarelor două sau trei release-uri. Era „Python nu poate face paralelism CPU-bound” se încheie. Îl atingem pe scurt în modulul 8 (concurrency).
asyncio ajuns la maturitate (tot ce s-a întâmplat din 3.7). async/await a încetat să fie controversat. Fiecare framework web major, fiecare driver de bază de date care merită folosit, fiecare SDK de cloud are acum o poveste async funcțională. Modulul 8 al cursului îi e dedicat.
Mutarea de ecosistem despre care chiar trebuie să știi
Caracteristicile de limbaj se rezumă ușor. Schimbarea mai mare din ultimii doi ani este mutarea de tooling, și e cea care îți afectează genuin felul în care îți petreci ziua.
Packaging-ul e mâncat de uv. Vreo douăzeci de ani, răspunsul la „cum instalez un pachet Python” a fost pip install. Răspunsul la „cum îl izolez de Python-ul de sistem” a fost python -m venv. Răspunsul la „cum îmi blochez dependențele” a fost pip-tools, poetry sau pipenv, în funcție de anul în care ai absolvit. Era o harababură.
În 2024, o companie numită Astral (aceeași oameni din spatele lui ruff) a lansat uv, scris în Rust, făcând tot ce am descris mai sus (și înlocuind pyenv pentru instalarea interpretorilor) într-un singur binar, cam de 10-100x mai rapid decât pip. Până la finalul lui 2025 devenise alegerea implicită în atelierele Python serioase pentru proiecte noi. Până în mai 2026, o mașină proaspăt configurată de dezvoltator Python e, din ce în ce mai des, doar uv și un editor.
Vom instala uv în lecția 4 și-l vom folosi pe tot parcursul restului cursului. Dacă ai folosit pip și venv înainte, memoria musculară se transferă; pur și simplu scrii uv în loc de python -m venv și pip install, iar totul e mai rapid. Dacă n-ai folosit niciuna, cu atât mai bine: înveți direct calea modernă și nu trebuie să dezveți pe cea veche.
pip, virtualenv și poetry nu pleacă nicăieri. Proiectele existente le folosesc în continuare. Cu siguranță vei întâlni fișiere requirements.txt, pyproject.toml și Pipfile.lock în sălbăticie ani buni de acum încolo. Vom acoperi ce este fiecare și cum să le tratăm. Dar pentru proiecte noi, în 2026, uv e implicit.
Linting-ul și formatting-ul s-au consolidat în ruff. Aceeași companie. Aceeași viteză Rust. ruff a înlocuit flake8, pylint (oarecum), isort și black cu o singură unealtă care rulează la fiecare salvare și e prea rapidă ca s-o observi. Dacă editorul tău nu rulează ruff la salvare până la lecția 8 a cursului, ceva e în neregulă.
Type checking: pyright i-a luat prânzul lui mypy. Ambele există încă, ambele funcționează. mypy (originalul, de la Dropbox/Guido) e mai configurabil și are păreri ușor diferite despre cazurile la limită. pyright (de la Microsoft, scris în TypeScript, inclus în VS Code prin extensia Pylance) e semnificativ mai rapid și e cel pe care e verificat majoritatea codului nou. Dacă folosești VS Code sau Cursor, folosești pyright, fie că ai observat, fie că nu. Le tratăm pe amândouă, dar implicit în acest curs e pyright.
Asistenții AI fac parte din toolchain acum. Copilot, Claude, Cursor: să te prefaci că nu există nu e o poziție serioasă în 2026. Vom discuta în lecția 2 despre cum să scrii cod într-un fel care îi face genuin utili (indiciu: type hints) și vom discuta mai târziu în curs despre când sugestiile lor sunt probabil greșite (în general: orice implică comportament async subtil, orice implică stratul de date al companiei tale specifice și orice loc unde inventează încrezători o bibliotecă inexistentă).
„Python e lent”: o dezbatem o dată, apoi mergem mai departe
Vei auzi, pentru totdeauna, că Python e lent. Nu e greșit, exact, dar e cadrul greșit.
Python e lent la calcul CPU-bound într-o buclă strânsă în Python pur. O buclă for care face aritmetică în Python pur e cam de 50x mai lentă decât echivalentul în C. E un fapt real și nu s-a schimbat fundamental.
Dar aproape niciun job real de Python nu e asta. Job-urile reale de Python fac astfel de muncă:
- Primesc o cerere HTTP, interoghează o bază de date, formatează JSON, returnează un răspuns. Bottleneck-ul e round-trip-ul la baza de date și rețeaua. Overhead-ul Python e în zgomot.
- Citesc un fișier Parquet cu
polarssaupyarrow, transformă niște coloane, îl scriu pe disc. Calculul real rulează în Rust sau C++ apelat dintr-un strat subțire de orchestrare în Python. Overhead-ul Python e în zgomot. - Antrenează un model de machine learning cu
pytorch. Matematica rulează pe un GPU în CUDA. Python e dirijorul; nu e în orchestră. - Lipesc trei API-uri SaaS unele de altele. Bottleneck-ul e latența HTTP. Overhead-ul Python e în zgomot.
Unde Python e genuin răspunsul greșit: motoare de joc în timp real, cod numeric pe traseu fierbinte fără numpy/torch/jax, sisteme embedded cu kilobytes de RAM și genul de high-frequency trading în care o microsecundă te costă un milion de dolari. Pentru orice altceva, munca pe care o facem majoritatea, Python e suficient de rapid, devine mai rapid la fiecare release, iar câștigul de productivitate plătește costul de runtime de o sută de ori.
Asta e ultima dată când o discutăm. Dacă cineva la un code review îți spune „Python e lent, ar trebui să rescrii asta în Go”, cere-i să facă întâi benchmark. Aproape niciodată n-o face.
Ce urmează în restul cursului
Zece module, în mare:
- Python în 2026 (ești aici): privire generală asupra limbajului, configurarea mediului, toolchain-ul modern.
- Sintaxă și tipuri: variabile, control flow, funcții, type hints, noile generics.
- Structuri de date: liste, dicts, sets, tuples, dataclasses, comprehensions, când să apelezi la fiecare.
- Iteratori, generatori și protocolul de iterație: sala de mașini a Python; înțelegerea ei schimbă totul.
- Python orientat pe obiecte: clase, moștenire, dunder methods, protocols, povestea
dataclass. - Erori, logging și debugging: excepții,
logging,pdb, profiling, cum arată ce e bun. - Turul bibliotecii standard:
pathlib,datetime,collections,itertools,functools,subprocess,json, modululos. - Concurrency: thread-uri, procese,
asyncio, Python free-threaded, când folosești ce. - Testare și packaging:
pytest, fixtures, mocking,pyproject.toml, publicare pe PyPI, semantic versioning. - Un proiect real, cap-coadă: construim o aplicație CLI mică, dar realistă, cu teste, tipuri, un pipeline CI și un release. Ultimele zece lecții.
Lecția 2 începe cu subiectul nesexy, dar critic, pe care fiecare bază de cod Python modernă îl așteaptă acum: type hints. Nu mai sunt opționale, deși runtime-ul încă se preface că sunt.
Lecturi suplimentare
- Documentația oficială Python: baza ta de pornire.
- What’s New in Python 3.13: release notes-urile sunt surprinzător de citibile.
- PEP 703: Making the GIL Optional in CPython: propunerea de free-threading.
- Astral blog: pentru a ține pasul cu
uvșiruff.
Ne vedem vineri pentru type hints.