Python er et programmeringssprog på højt niveau.
Nyheden brød for nylig om, at Python Project Steering Committee har meddelt sit ønske om at godkende Python-sprogudvidelsesforslag «PEP-0703", hvilket gør den globale fortolkerlås valgfri i CPython, og som grundlæggende definerer indlejringen af CPython-kompileringstilstand uden Global Interpreter Lock (GIL).
PEP-0703 definerer at stoppe med at bruge GIL som standard, men tilføj byggemuligheden "–sin-gil" for at deaktivere den. Hvordan har du detl Den nye tilstand forventes at løse problemet med parallelisering af operationer på multi-core systemer, forårsaget af det faktum, at den globale lås ikke tillader parallel adgang til delte objekter fra forskellige tråde.
Det nævnes, at på længere sigt (efter 5 år), shell er planlagt til at blive ændret som standard til kun i global ikke-låsende tilstand, samtidig med at man dropper støtte til kompilering med GIL.
Tak til jer alle for at svare på undersøgelsen om no-GIL-forslaget. Det er klart, at den generelle stemning er positiv, både for den generelle idé og for PEP 703 i særdeleshed. Bestyrelsen er også stort set positiv til begge dele. Vi har til hensigt at acceptere PEP 703, selvom vi stadig arbejder på detaljerne for accept.
Som vi har gjort et par gange tidligere, ønsker vi at kommunikere vores hensigt om at acceptere PEP sammen med vores nuværende tankegang om detaljerne i forbindelse med accept.
Udover det, Det nævnes, at de ændringer, der planlægges gennemført i tre etaper, som er kort, mellemlang og lang sigt. I betragtning af det i den første fase er det upraktisk at deaktivere GIL som standard på grund af de overhead, der er forbundet med ændringer i skraldeopsamleren, hukommelsesstyringssystemet og primitiverne for at organisere låse. På grund af brugen af referencetælling til trådisolering er der f.eks. et ydelsesfald for enkelttrådede scripts (i pyperformance-testpakken med 10%). Samtidig kan det være nødvendigt at deaktivere GIL i videnskabelig databehandling, hvor manglen på parallelisering er et mere alvorligt problem end den lineære hastighed af kodeudførelse.
I anden fase vil man som udgangspunkt afvente bekræftelsen. og at der er tilstrækkelig opbakning fra samfundet til at brugen af "ikke-GIL er levedygtig" og sørg for, at GIL-fri build er understøttet, men ikke standard.
I sidste fase vil no-GIL allerede være standardværdien og eventuelle rester af GIL vil blive fjernet (uden unødigt at bryde bagudkompatibiliteten).
Det observeres, at arbejdet med at flytte væk fra GIL vil blive udført meget omhyggeligt for ikke at gentage fejlen hvad der skete ved promovering Python 3: En ikke-GIL-build skal sikre kompatibilitet med ældre versioner af Python, og eventuelle tredjepartskodeændringer, der kræves for at fungere på ikke-GIL-builds, bør også fungere på GIL-builds.
Der er ingen planer om at omnummerere versionerne til Python 4 for ikke-GIL-builds, da de vil opretholde ABI-kompatibilitet.
Gennem hele processen skal vi (kerneudviklerne, ikke kun SC) revurdere fremskridt og foreslåede tidslinjer. Vi ønsker ikke, at dette skal blive endnu en ti-årig bagudkompatibilitetskamp, og vi vil gerne være i stand til at annullere PEP 703 og finde en anden løsning, hvis det ser ud til at blive problematisk, så vi er nødt til regelmæssigt at kontrollere, at det fortsatte arbejde er det værd.
Vi håber, at dette giver en vis klarhed om fremtiden for PEP'et, mens vi udarbejder de nøjagtige detaljer for accept. SC vil arbejde på at afslutte accepten i de kommende uger.
Inden den fulde overgang til ikke-GIL-builds, planlægger vi at opnå fuld fællesskabsunderstøttelse for disse builds, samt at levere yderligere C API'er og Python API'er for at muliggøre sikker multithreading i eksisterende kode.
Endelig, som allerede nævnt, forventes det, at overgangen til tredje fase kan ske om mindst 5 år, og den sandsynlige dato for PEP-0703 er udgivelsen af Python 3.13, planlagt til næste efterår.
Hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne I det følgende link.