Prețul migrării Mercurial la Python 3 poate fi o urmă de erori neașteptate.

Menținătorul sistemului de control al versiunilor ager lasă-mă jos rezultat lucrează la transferul proiectului de la Python 2 la Python 3. În ciuda faptului că primele încercări de portare au fost făcute în 2008 și adaptarea accelerată pentru lucrul cu Python 3 a început în 2015, capacitatea deplină de a utiliza Python 3 a fost implementată abia în ultima perioadă. ramură a lui Mercurial 5.2.

Predicțiile despre stabilitatea portului pentru Python 3 sunt dezamăgitoare. În special, este de așteptat ca în cod să apară erori aleatorii de-a lungul mai multor ani, deoarece testele nu acoperă 100% din baza de cod, iar multe probleme sunt invizibile în timpul analizei statice și apar doar în timpul execuției. În plus, multe suplimente și extensii terțe rămân netraduse în Python 3.
Deoarece în timpul portarii s-a decis adaptarea treptată a codului la Python 3, menținând în același timp suportul pentru Python 2, codul a dobândit multe hack-uri pentru a combina Python 2 și 3, care vor trebui curățate după terminarea suportului pentru Python 2.

Comentând situația cu Python 3, întreținătorul Mercurial consideră că decizia de a promova Python 3 care distruge interoperabilitatea și de a-l impune ca un limbaj nou, mai corect, în absența unor îmbunătățiri inovatoare relevante pentru dezvoltatori, a fost o mare greșeală care a provocat mare prejudiciu pentru comunitate și este un exemplu al modului în care proiectele mari nu trebuie să facă acest lucru. În loc să construiască treptat funcționalități și să permită personalizarea progresivă a aplicațiilor, lansarea Python 3 a forțat dezvoltatorii să rescrie codul și să cheltuiască resurse menținând ramuri separate pentru Python 2 și Python 3. Abia după șapte ani de la lansarea Python 3.0 Python 3.5 a introdus funcții pentru a ușura procesul de tranziție și pentru a se asigura că aceeași bază de cod rulează atât Python 2, cât și Python 3.

Sursa: opennet.ru

Adauga un comentariu