Alegeți paralelismul Python după datele care trec între interpretoare

O interfață familiară pentru executarea sarcinilor poate ascunde un model diferit de gestionare a datelor. Grupurile de interpretoare Python permit rularea în interpretoare separate, dar o aplicație în care lucrătorii modifică același dicționar nu poate înlocui pur și simplu executorul, așteptând același comportament. Alegeți modelul de execuție paralelă după informația care trebuie transmisă între lucrători și componenta responsabilă de reunirea rezultatelor.

Privind retrospectiv din noiembrie 2026, lansarea relevantă este Python 3.14.0, din 7 octombrie 2025. PEP 734 a fost creat la 6 noiembrie 2023 și indică Python 3.14 drept versiune vizată. Data creării marchează începutul unei propuneri, nu lansarea funcționalității din biblioteca standard. Separarea contează când reconstituiți ce puteau adopta efectiv echipele în octombrie 2025.

Fiecare lucrător are propriul interpretor

Documentația executorilor pentru Python 3.14, consultată în noiembrie 2026 ca documentație modificabilă, etichetată atunci 3.14.10, descrie concurrent.futures.InterpreterPoolExecutor ca subclasă a ThreadPoolExecutor. Fiecare lucrător rulează în propriul fir și are propriul interpretor. Fiecare interpretor are propriul GIL, ceea ce permite executarea codului Python din interpretoare diferite pe nuclee CPU diferite.

Aceeași documentație descrie stări de execuție izolate, obiecte de modul importate separat și absența partajării automate a obiectelor modificabile. Executorul serializează funcțiile trimise, argumentele și valorile returnate folosind pickle. Valorile nemodificabile au alte condiții de partajare; API-urile de nivel inferior pentru interpretoare oferă și mecanisme controlate de comunicare. Aceste fapte descriu o limită de schimb de date. Nu promit că transferul este gratuit sau că orice obiect folosit deja de aplicație poate trece cu succes prin acest mecanism.

PEP-ul acceptat numește modulul de nivel inferior concurrent.interpreters; textul propunerii păstrează și discuții despre numele propus anterior. Separați modulul lansat de API-ul executorului. Posibilitatea de a crea interpretoare și de a comunica între ele este mai largă decât modelul executorului, bazat pe trimiterea unei sarcini și returnarea rezultatului. Documentația din eticheta CPython 3.14.0 consemnează separat comportamentul executorului la acea lansare. Niciuna dintre denumiri nu înseamnă că obiectele Python modificabile obișnuite devin o bază de date comună aplicației.

O sarcină ipotetică de prelucrare a documentelor face distincția concretă. Un coordonator poate distribui documente independente și reuni rezumatele primite. Transmiterea conținutului documentelor are un cost pe care aplicația ar avea nevoie să îl evalueze. Transmiterea unui identificator poate reduce transferul, dar fiecare lucrător are atunci nevoie de o cale autorizată de a prelua documentul. Alegerea unor argumente mai mici mută responsabilitatea; nu o elimină.

Stabiliți cine răspunde de rezultatul final

Izolarea poate clarifica responsabilitățile. Un lucrător poate calcula un rezultat din date de intrare explicite, iar coordonatorul decide cum îl salvează. Proiectarea devine mai dificilă când sarcina se așteaptă să modifice o memorie cache comună, să refolosească o conexiune activă a apelantului sau să publice actualizări schimbând o variabilă de modul. Aceste așteptări cer reproiectare, nu schimbarea numelui executorului.

Importurile separate fac și din inițializare o parte a planului. Configurarea unui modul în interpretorul principal nu implică existența unui modul configurat echivalent în fiecare lucrător. Definiți pregătirea necesară și ce se întâmplă dacă eșuează. Un lucrător indisponibil nu ar trebui să transforme pe ascuns o colecție incompletă de rezultate într-un raport reușit. Produsul are nevoie să distingă un element eșuat de un rezultat gol.

Reîncercările ridică o problemă înrudită. Dacă un lucrător scrie într-un serviciu extern, iar coordonatorul pierde rezultatul, repetarea sarcinii poate repeta scrierea. Izolarea interpretoarelor nu garantează că repetarea unei operații asupra bazei de date sau a unui API extern are același efect ca o singură execuție. Atribuiți sarcinilor identități stabile și definiți tratarea duplicatelor oriunde repetarea efectelor ar fi dăunătoare. Acestea rămân cerințe ale aplicației chiar dacă lucrătorii nu împart stare Python modificabilă.

Limita este și una operațională. Interpretoarele rămân în același proces, deci nu ar trebui prezentate ca izolare a defecțiunilor la nivel de proces sau ca mediu de securitate pentru cod ostil. Alegeți un proces separat ori o izolare mai puternică atunci când aceasta este cerința reală. Starea de execuție privată și un proces protejat separat de sistemul de operare rezolvă probleme diferite.

Paralelismul nu este un verdict de performanță

Cel mai puternic contraargument este costul separării datelor. Un set mare de date modificabile, coordonarea frecventă sau o extensie nepotrivită pentru interpretoare izolate pot face alt model mai practic. Verificați compatibilitatea extensiilor pentru versiunea instalată efectiv și îndrumările autorilor lor. Un anunț de lansare Python nu poate certifica toate dependențele native ale unei aplicații.

Firele de execuție pot rămâne potrivite pentru așteptarea operațiilor externe sau pentru cod al cărui lucru nativ relevant eliberează GIL-ul. Procesele pot fi potrivite când separarea la nivel de proces are valoare. Python fără GIL global este o altă opțiune, cu propriile condiții privind compilarea și dependențele. GIL-urile separate pe interpretor și un mediu comun fără GIL global sunt modele diferite; suportul pentru unul nu dovedește un comportament echivalent de partajare în celălalt.

Articolul nu execută un test comparativ al grupurilor de lucrători și nu afirmă o accelerare. Orice comparație ar avea nevoie de dimensiunea reală a sarcinii, volumul serializat, costul inițializării și extensiile instalate. Ar avea nevoie și de verificarea corectitudinii la eșec parțial. Măsurarea timpului pentru un rezultat care omite pe ascuns documentele eșuate ar răspunde altei întrebări decât cea a produsului.

Descrieți schimbul de date înainte să alegeți executorul

Începeți cu o sarcină descrisă fără vocabularul concurenței. Precizați datele de intrare, rezultatul, efectele externe și cine are dreptul să o repete. Identificați apoi informația care chiar trebuie partajată în timpul lucrului. Dacă lista este lungă, grupul de interpretoare poate scoate la iveală o cuplare care merită rezolvată sau poate fi pur și simplu nepotrivit pentru sarcină.

Pentru software la comandă, conveniți regulile privind rezultatele complete și reîncercările împreună cu structura schimbului de date. Grupurile de interpretoare merită luate în calcul când lucrul independent și schimbul explicit respectă acele reguli. Rezultatul util este un program ale cărui responsabilități rămân clare în execuția paralelă, nu schimbarea executorului justificată doar de apariția unei versiuni noi.