La prezo de migrado de Mercurial al Python 3 povas esti spuro de neatenditaj eraroj.

Versiokontrolsistemo prizorganto Merkurio lasu min malsupren rezulto labori pri translokigo de la projekto de Python 2 al Python 3. Malgraŭ la fakto, ke la unuaj porportaj provoj estis faritaj en 2008, kaj akcelita adaptado por labori kun Python 3 komenciĝis en 2015, la plena kapablo uzi Python 3 estis efektivigita nur en la plej lasta tempo. branĉo de Mercurial 5.2.

Antaŭdiroj pri la stabileco de la haveno por Python 3 estas seniluziigaj. Precipe, estas atendite ke hazardaj eraroj aperos en la kodo dum pluraj jaroj, ĉar testoj ne kovras 100% de la koda bazo, kaj multaj problemoj estas nevideblaj dum senmova analizo kaj nur aperas ĉe rultempo. Krome, multaj triaj aldonaĵoj kaj etendaĵoj restas netradukitaj al Python 3.
Ĉar dum la portado oni decidis iom post iom adapti la kodon al Python 3, konservante subtenon por Python 2, la kodo akiris multajn hakojn por kombini Python 2 kaj 3, kiuj devos esti purigitaj post finiĝo de subteno por Python 2.

Komentante la situacion kun Python 3, la prizorganto de Mercurial opinias, ke la decido antaŭenigi la interfunkcieblan rompantan Python 3 kaj trudi ĝin kiel novan, pli ĝustan lingvon, pro manko de progresaj plibonigoj rilataj al programistoj, estis granda eraro, kiu kaŭzis. granda damaĝo al la komunumo kaj estas ekzemplo de kiel ne grandaj projektoj devas fari tion. Anstataŭ iom post iom konstrui funkciecon kaj permesi al aplikaĵoj esti laŭgrade personecigitaj, la liberigo de Python 3 devigis programistojn reverki kodon kaj elspezi rimedojn konservante apartajn branĉojn por Python 2 kaj Python 3. Ne daŭris ĝis sep jaroj post la liberigo de Python 3.0 tio Python 3.5 enkondukis funkciojn por glatigi transigan procezon kaj certigi, ke la sama kodbazo funkcias kaj Python 2 kaj Python 3.

fonto: opennet.ru

Aldoni komenton