Python 3.14 a fost lansat pe 7 octombrie 2025. Aici rezumăm câteva dintre schimbările mai interesante și unele tendințe în dezvoltarea Python și știința datelor din ultimul an. Vom evidenția următoarele:
- interfața colorată de linie de comandă Python;
- instrument de management de proiect
uv; - cu filet liber;
- și un scurt rezumat al altor evoluții.
Notele de lansare Python 3.14 descriu, de asemenea, modificările aduse Python-ului de bază.
REPL colorat
La Jumping Rivers am învățat mulți oameni să programeze în Python. De-a lungul unei cariere de programare te obișnuiești să faci și să înveți din greșeli. Cele mai frecvente greșeli făcute în lecțiile introductive de programare vă pot încărca peste 10 ani: paranteze nepotrivite, greșeli de scriere, simboluri lipsă de ghilimele, dependențe neimportate.
Cursurile noastre de instruire Python sunt prezentate folosind Jupyter. Caietele Jupyter au evidențiere de sintaxă care facilitează identificarea unui șir neterminat sau a unui cuvânt cheie scris greșit.
Dar, majoritatea cursanților Python nu folosesc Jupyter (sau alte instrumente de programare de nivel înalt) în prima zi – experimentează cu Python la linia de comandă. Puteți introduce „python” în fereastra shell/terminal și puteți începe programarea în „REPL” (bucla de citire-evaluare-printare).
Orice efort de a face mai ușor de lucrat cu REPL va fi benefic pentru programatorii începători. Prin urmare, introducerea evidențierii sintaxei în Python 3.14 REPL este cu adevărat benefică.
uv și dezvoltarea pachetelor
Una dintre tendințele mari în dezvoltarea Python în 2025 este ascensiunea instrumentului de management de proiect.
uv. Acesta este un instrument de linie de comandă bazat pe Rust și poate fi folosit pentru a inițializa o structură de pachet/proiect, pentru a specifica mediul de dezvoltare și de rulare al unui proiect și pentru a publica un pachet în PyPI.
La Jumping Rivers, am folosit poetry pentru multe dintre locurile de muncă care uv
excelează la. Python este folosit pentru sarcinile de pregătire a datelor pentru diffify.com, iar noi folosim
poetry pentru a ne asigura că dezvoltatorii noștri folosesc fiecare exact aceleași versiuni de pachet atunci când lucrează la acel proiect (vezi seria noastră actuală de bloguri despre Poezie). Dar,
poetry nu împiedică dezvoltatorii să folosească versiuni diferite de Python. Pentru asta, avem nevoie de un al doilea instrument de genul
pyenv (care permite comutarea între diferite versiuni Python) sau ca fiecare dezvoltator să aibă aceeași versiune Python instalată pe computer.
uv merge cu un pas mai departe de poetry și ne permite să fixăm versiunile Python pentru un proiect. Să folosim uv pentru a instala Python 3.14, astfel încât să putem testa funcțiile din noua versiune.
Mai întâi urmați instrucțiunile de instalare uv.
Apoi, la linia de comandă, vom folosi uv pentru a crea un nou proiect în care vom folosi Python 3.14.
# (bash) cd ~/temp mkdir blog-py3.14 cd blog-py3.14 # Which versions of Python 3.14 are available via uv? uv python list | grep 3.14 # cpython-3.14.0rc2-linux-x86_64-gnu# cpython-3.14.0rc2+freethreaded-linux-x86_64-gnu
Veți vedea ceva similar indiferent de sistemul de operare pe care îl utilizați. Aici sunt enumerate două versiuni de Python 3.14 – una cu un sistem opțional numit „Free Threading” (a se vedea mai târziu). Vom instala ambele versiuni de Python:
uv python install cpython-3.14.0rc2-linux-x86_64-gnu uv python install cpython-3.14.0rc2+freethreaded-linux-x86_64-gnu
Utilizatorii de pyenv va putea instala Python 3.14 într-un mod similar.
Putem selecta dintre cele două versiuni diferite de Python la linia de comandă. Mai întâi folosiți versiunea care nu are threading gratuit:
uv run --python=3.14 python # Python 3.14.0rc2 (main, Aug 18 2025, 19:19:22) (Clang 20.1.4 ) on linux # ... >>> import sys >>> sys._is_gil_enabled() # True
Apoi, folosind versiunea cu threading gratuit (rețineți că t sufix)
uv run --python=3.14t python # ... # Python 3.14.0rc2 free-threading build (main, Aug 18 2025, 19:19:12) (Clang 20.1.4 ) on linux # ... >>> import sys >>> sys._is_gil_enabled() # False
Crearea si managementul proiectelor cu uv
uv este capabil de mult mai mult decât să ne permită să comutăm între diferite versiuni de Python. Următoarele comenzi inițializează un proiect Python cu uv:
# From ~/temp/blog-py3.14 # Indicate the default python version for the project uv python pin 3.14 # Initialise a project in the current directory uv init . # Check the Python version uv run python --version # Python 3.14.0rc2
Aceasta adaugă câteva fișiere pentru metadatele proiectului (pyproject.toml, README.md) și controlul versiunilor:
tree -a -L 1 # . # ├── .git # ├── .gitignore # ├── main.py # ├── pyproject.toml # ├── .python-version # ├── README.md # ├── uv.lock # └── .venv # # 2 directories, 6 files
Acum putem adăuga dependențe de pachet folosind uv add și alte sarcini standard de management de proiect. Dar un lucru pe care am vrut să-l subliniez este că uv ne permite să pornim un notebook Jupyter, folosind interpretul Python al proiectului, fără a adăuga nici jupyter ca dependență sau definirea explicită a unui nucleu pentru jupyter:
uv run --with jupyter jupyter lab
Crearea unui nou blocnotes folosind nucleul Python 3 implicit în sesiunea JupyterLab care începe, ar trebui să vă asigure că utilizați mediul Python 3.14 activ în prezent.
Filetat
Python 3.13 a introdus o caracteristică experimentală, „Free-threading”, care este acum acceptată oficial începând cu 3.14.
În primul rând, ce este un „fir”? Când un program rulează pe computerul dvs., există o mulțime de sarcini diferite. Unele dintre aceste sarcini ar putea rula independent unele de altele. Dvs., în calitate de programator, poate fi necesar să explicați computerului ce sarcini pot rula independent. Un fir este o modalitate de izolare a uneia dintre aceste sarcini; este un mod de a-i spune computerului că software-ul tău rulează, că această sarcină aici poate rula separat de acele sarcini de acoloși logica pentru alergare
această sarcină prea. (Practic).
Python a permis dezvoltatorilor să definească fire de execuție pentru o perioadă. Dacă aveți câteva sarcini care sunt în mare măsură independente unele de altele, fiecare dintre aceste sarcini poate rula într-un fir separat. Threadurile pot accesa același spațiu de memorie, ceea ce înseamnă că pot accesa și modifica variabilele partajate într-o sesiune Python. În general, aceasta înseamnă, de asemenea, că un calcul într-un fir de execuție ar putea actualiza o valoare care este utilizată de un alt fir de execuție sau că două fire diferite ar putea face actualizări contradictorii aceleiași variabile. Această libertate poate duce la bug-uri. Interpretul CPython a fost scris inițial cu un mecanism de blocare (Global Interpreter Lock, GIL) care a împiedicat rularea diferitelor fire de execuție în același timp (chiar și atunci când mai multe procesoare erau disponibile) și a limitat accesul acestor erori.
În mod tradițional, ați fi folosit fire de execuție pentru „sarcini care nu sunt legate de CPU” în Python. Acestea sunt tipurile de sarcini care nu ar fi afectate de a avea mai multe procesoare sau mai rapide disponibile pentru instanța Python: trafic de rețea, acces la fișiere, așteptarea intrării utilizatorului. Pentru sarcini legate de CPU, cum ar fi calculele și procesarea datelor, puteți utiliza biblioteca „multiprocesare” a lui Python (deși unele biblioteci precum „numpy” au propriile mecanisme de nivel scăzut pentru împărțirea lucrărilor între nuclee). Aceasta pornește mai multe instanțe Python, fiecare făcând o parte din procesare și permite ca o încărcătură de lucru să fie partiționată pe mai multe procesoare.
Celelalte diferențe principale între threading și multiprocesare în Python sunt în gestionarea memoriei și a datelor. Cu threading, aveți o instanță Python, fiecare fir având acces la același spațiu de memorie. Cu multiprocesare, aveți mai multe instanțe Python care funcționează independent: instanțele nu partajează memorie, așa că pentru a partiționa o sarcină de lucru folosind multiprocesare, Python trebuie să trimită copii ale (subseturi ale) datelor dumneavoastră către noile instanțe. Acest lucru ar putea însemna că trebuie să stocați două sau mai multe copii ale unui set de date mare în memorie atunci când utilizați multiprocesare pe acesta.
Procesarea simultană între firele de execuție care împart spațiul de memorie este acum posibilă folosind versiunea Python cu fire libere. Multe pachete terță parte au fost rescrise pentru a se adapta la această nouă versiune și puteți afla mai multe despre free-threading și progresul modificărilor în „Ghidul Python Free-Threading”.
Ca exemplu simplu, să luăm în considerare procesarea limbajului natural. Există o postare minunată pe blog despre procesarea paralelă cu
nltk pachet pe „Blogul WZB Data Science”. Vom extinde acest exemplu pentru a folosi free-threading.
ntlk oferă acces la unele dintre cărțile Proiectului Gutenberg și putem accesa aceste date după cum urmează:
# main.py
import nltk
def setup():
nltk.download("gutenberg")
nltk.download("punkt_tab")
nltk.download('averaged_perceptron_tagger_eng')
corpus = { f_id: nltk.corpus.gutenberg.raw(f_id)
for f_id in nltk.corpus.gutenberg.fileids()
}
return corpus
corpus = setup()
Perechile cheie-valoare în corpus sunt titlul prescurtat al cărții și conținutul pentru 18 cărți. De exemplu:
corpus("austen-emma.txt")
# (Emma by Jane Austen 1816)
#
# VOLUME I
#
# CHAPTER I
#
#
# Emma Woodhouse, handsome, clever, and rich, with a comfortable home ...
O parte standard a unui flux de lucru de procesare a textului este tokenizarea și etichetarea „părților de vorbire” (POS) dintr-un document. Putem face acest lucru folosind două nltk
functii:
# main.py ... continued def tokenise_and_pos_tag(doc): return nltk.pos_tag(nltk.word_tokenize(doc))
O funcție de tokenizare și etichetare POS secvențială a conținutului unui corpus de cărți poate fi scrisă:
# main.py ... continued
def tokenise_seq(corpus):
tokens = {
f_id: tokenise_and_pos_tag(doc)
for f_id, doc in corpus.items()
}
return tokens
Trebuie să instalați sau să construiți Python într-un mod special pentru a utiliza Python „Free-threaded”. În cele de mai sus, am instalat Python „3.14t” folosind
uvastfel încât să putem compara viteza de procesare cu fire libere și secvențială, cu un singur nucleu.
Vom folosi
timeit pachet pentru a analiza viteza de procesare, din linia de comandă.
# Activate the threaded version of Python 3.14 uv python pin 3.14t # Install the dependencies for our main.py script uv add timeit nltk # Time the `tokenise_seq()` function # -- but do not time any setup code... PYTHON_GIL=0 uv run python -m timeit --setup "import main; corpus = main.setup()" "main.tokenise_seq(corpus)" # (lots of output messages) # 1 loop, best of 5: 53.1 sec per loop
După câțiva pași inițiali în care nltk seturile de date au fost descărcate și
corpus obiectul a fost creat (nici unul dintre acestea nu a fost cronometrat, deoarece acești pași făceau parte din timeit --setup bloc), tokenise_seq(corpus) a fost rulat de mai multe ori și cea mai mare viteză a fost de aproximativ 53 de secunde.
O mică notă: am folosit variabila de mediu PYTHON_GIL=0 Aici. Acest lucru face explicit faptul că folosim free-threading (dezactivarea GIL). În mod normal, acest lucru nu ar fi necesar pentru a profita de free-threading (în Python „3.14t”), dar a fost necesar deoarece una dintre dependențele de nltk nu a fost validat încă pentru versiunea cu thread-uri libere.
Pentru a scrie o versiune threaded a acesteia, introducem două funcții. Primul este un ajutor care preia perechi (nume fișier, document-conținut) și returnează perechi (nume fișier, document procesat):
def tupled_tokeniser(pair): file_id, doc = pair return file_id, tokenise_and_pos_tag(doc)
A doua funcție creează un grup de fire, profitând de atâtea procesoare câte sunt disponibile pe mașina mea (16, numărate după multiprocessing.cpu_count()). Fiecare document este procesat ca un fir separat și așteptăm ca toate documentele să fie procesate înainte de a returna rezultatele apelantului:
import multiprocessing as mp from concurrent.futures import ThreadPoolExecutor, wait # ... def tokenise_threaded(corpus): with ThreadPoolExecutor(max_workers=mp.cpu_count()) as tpe: try: futures = ( tpe.submit(tupled_tokeniser, pair) for pair in corpus.items() ) wait(futures) finally: # output is a list of (file-id, data) pairs tokens = (f.result() for f in futures) return tokens # Time the `tokenise_threaded()` function # -- but do not time any setup code... PYTHON_GIL=0 uv run python -m timeit --setup "import main; corpus = main.setup()" "main.tokenise_threaded(corpus)" # (lots of output messages) # 1 loop, best of 5: 32.5 sec per loop
Am putut vedea că fiecare nucleu a fost folosit la procesarea documentelor, folosind
htop instrument pe Ubuntu. În anumite momente în timpul rulării, fiecare dintre cele 16 procesoare a fost la o utilizare aproape de 100% (în timp ce doar unul sau două procesoare au fost ocupate în orice moment în timpul rulării secvenţiale):
Dar, în ciuda utilizării de 16 ori mai multe procesoare, versiunea multithreaded a scriptului de procesare a fost doar cu aproximativ 40% mai rapidă. În setul de date erau doar 18 cărți și o oarecare diferență între lungimile cărților (Biblia, care conținea milioane de cuvinte, a fost procesată mult mai lent decât celelalte). Poate că viteza ar fi mai mare cu un set de date mai mare sau mai echilibrat.
În postarea de pe blogul WZB Data Science, există o implementare de multiprocesare a celor de mai sus. Rularea codului lor de multiprocesare cu 16 procesoare a dat o viteză similară până la multithreading (timp minim 31,2 secunde). Într-adevăr, dacă aș scrie acest cod pentru un proiect real, multiprocesarea ar rămâne alegerea mea, deoarece analiza pentru o carte poate continua independent de cea pentru orice altă carte și volumele de date nu sunt atât de mari.
Alte Stiri
Python 3.14 a introdus, de asemenea, unele îmbunătățiri în gestionarea excepțiilor, o nouă abordare a șablonului de șiruri și îmbunătățiri la utilizarea interpreților concurenți. Consultați notele de lansare Python 3.14 pentru mai multe detalii.
În ecosistemul mai larg Python Data Science, alte câteva evoluții au avut loc sau sunt programate înainte de sfârșitul anului 2025:
- Prima lansare stabilă a Positron IDE a fost făcută în august;
- Pandas 3.0 este programat înainte de sfârșitul anului și va introduce șiruri de caractere ca tip de date, comportament de copiere la scriere și acces implicit la coloanele din codul de modificare DataFrame;
- Instrumentele care ingerează DataFrame devin agnostice pentru biblioteca DataFrame prin proiectul Narwahls. Vedeți articolul Plotly pe acest subiect.
Pentru actualizări și revizuiri ale acestui articol, consultați postarea inițială
