Ang Python ay isang mataas na antas ng programming language.
Kamakailan ay lumabas ang balita na ang Inihayag ng Python Project Steering Committee ang pagnanais nitong aprubahan ang Panukala sa pagpapalawig ng wikang Python «PEP-0703″, ginagawang opsyonal ang pandaigdigang interpreter lock sa CPython at na karaniwang tumutukoy sa pag-embed ng CPython compile mode nang walang Global Interpreter Lock (GIL).
PEP-0703 tumutukoy sa paghinto sa paggamit ng GIL bilang default, ngunit magdagdag ng pagpipilian sa pagbuo "–sin-gil" upang hindi paganahin ito. Kamusta kal Inaasahang malulutas ng bagong mode ang problema sa parallelization ng mga operasyon sa mga multi-core system, na sanhi ng katotohanan na ang global lock ay hindi nagpapahintulot ng parallel na pag-access sa mga nakabahaging bagay mula sa iba't ibang mga thread.
Nabanggit na sa mahabang panahon (pagkatapos ng 5 taon), Ang shell ay binalak na baguhin bilang default sa lamang sa pandaigdigang non-locking mode, habang sa parehong oras ay bumababa ng suporta para sa pag-compile sa GIL.
Salamat sa lahat ng tumugon sa survey sa panukalang no-GIL. Malinaw na positibo ang pangkalahatang damdamin, kapwa para sa pangkalahatang ideya at para sa PEP 703 sa partikular. Ang Lupon ng mga Direktor ay higit na positibo sa pareho. Balak naming tanggapin ang PEP 703, bagama't inaayos pa namin ang mga detalye ng pagtanggap.
Tulad ng ilang beses na naming ginawa sa nakaraan, gusto naming ipaalam ang aming intensyon na tanggapin ang PEP kasama ang aming kasalukuyang pag-iisip sa mga detalye na may kaugnayan sa pagtanggap.
Bukod diyan, Nabanggit na ang mga pagbabago na binalak na isagawa sa tatlong yugto, na maikli, katamtaman at mahabang panahon. Kung ganoon sa unang yugto, ang hindi pagpapagana ng GIL bilang default ay hindi praktikal dahil sa overhead na nauugnay sa mga pagbabago sa tagakolekta ng basura, ang sistema ng pamamahala ng memorya, at ang mga primitive para sa pag-aayos ng mga kandado. Halimbawa, dahil sa paggamit ng pagbibilang ng sanggunian para sa paghihiwalay ng thread, mayroong pagbaba ng pagganap para sa mga single-threaded na script (sa pyperformance test suite ng 10%). Kasabay nito, maaaring kailanganin na huwag paganahin ang GIL sa siyentipikong computing, kung saan ang kakulangan ng parallelization ay isang mas malubhang problema kaysa sa linear na bilis ng pagpapatupad ng code.
Sa ikalawang yugto, karaniwang ang kumpirmasyon ay hihintayin. at na may sapat na suporta mula sa komunidad upang ang paggamit ng "non-GIL ay mabubuhay" at siguraduhin na ang GIL-less build ay suportado ngunit hindi default.
Sa huling yugto, ang no-GIL na ang magiging default na halaga at ang anumang mga bakas ng GIL ay aalisin (nang hindi kinakailangang masira ang backward compatibility).
Naobserbahan na gagawing maingat ang trabahong lumayo sa GIL para hindi na maulit ang pagkakamali ano ang nangyari noong nagpo-promote Python 3: Kakailanganin ng isang build na hindi GIL upang matiyak ang pagiging tugma sa mga mas lumang bersyon ng Python, at anumang mga pagbabago sa code ng third-party na kinakailangan upang gumana sa mga build na hindi GIL ay dapat ding gumana sa mga build ng GIL.
Walang planong palitan ang bilang ng mga bersyon sa Python 4 para sa mga hindi GIL build, dahil pananatilihin nila ang pagiging tugma ng ABI.
Sa buong proseso, kami (ang mga pangunahing developer, hindi lamang ang SC) ay kakailanganing muling suriin ang pag-unlad at mga iminungkahing timeline. Hindi namin nais na ito ay maging isa pang sampung taon na backward compatibility fight, at gusto naming makansela ang PEP 703 at makahanap ng ibang solusyon kung ito ay magiging problema, kaya kailangan naming regular na suriin kung ang patuloy na trabaho ay katumbas ng halaga.
Umaasa kaming magbibigay ito ng kaunting linaw sa kinabukasan ng PEP habang ginagawa namin ang eksaktong mga detalye ng pagtanggap. Sisikapin ng SC na tapusin ang pagtanggap sa mga darating na linggo.
Bago ang buong paglipat sa mga build na hindi GIL, pinaplano naming makamit ang buong suporta ng komunidad para sa mga build na ito, pati na rin magbigay ng mga karagdagang C API at Python API upang paganahin ang ligtas na multithreading sa umiiral na code.
Sa wakas, tulad ng nabanggit na, inaasahan na ang paglipat sa ikatlong yugto ay maaaring mangyari sa hindi bababa sa 5 taon at ang posibleng petsa para sa PEP-0703 ay ang paglabas ng Python 3.13, na naka-iskedyul para sa susunod na taglagas.
Kung ikaw interesadong malaman ang higit pa tungkol dito, maaari mong suriin ang mga detalye Sa sumusunod na link.