Opiekun systemu kontroli wersji zawiedź mnie prace nad przeniesieniem projektu z Pythona 2 do Pythona 3. Pomimo tego, że pierwsze próby portingu podjęto już w 2008 roku, a przyspieszona adaptacja do pracy z Pythonem 3 rozpoczęła się w 2015 roku, pełną możliwość wykorzystania Pythona 3 zaimplementowano dopiero w najnowszych oddział Mercuriala 5.2.
Prognozy dotyczące stabilności portu dla Pythona 3 są rozczarowujące. W szczególności oczekuje się, że w kodzie będą pojawiać się przypadkowe błędy na przestrzeni kilku lat, ponieważ testy nie obejmują 100% bazy kodu, a wiele problemów jest niewidocznych podczas analizy statycznej i pojawia się dopiero w czasie wykonywania. Ponadto wiele dodatków i rozszerzeń innych firm nie zostało przetłumaczonych na język Python 3.
Ponieważ podczas przenoszenia zdecydowano się na stopniowe dostosowywanie kodu do Pythona 3, przy jednoczesnym zachowaniu wsparcia dla Pythona 2, w kodzie pojawiło się wiele hacków umożliwiających połączenie Pythona 2 i 3, które będą musiały zostać oczyszczone po zakończeniu wsparcia dla Pythona 2.
Komentując sytuację z Pythonem 3, opiekun Mercurial uważa, że decyzja o promowaniu psującego interoperacyjność Pythona 3 i narzuceniu go jako nowego, bardziej poprawnego języka, w obliczu braku przełomowych ulepszeń istotnych dla programistów, była dużym błędem, który spowodował wyrządzają wielką szkodę społeczności i jest przykładem na to, że nie trzeba tego robić przy dużych projektach. Zamiast stopniowo budować funkcjonalność i umożliwiać stopniowe dostosowywanie aplikacji, wydanie Pythona 3 zmusiło programistów do przepisania kodu i wydawania zasobów na utrzymanie oddzielnych gałęzi dla Pythona 2 i Pythona 3. Dopiero siedem lat po wydaniu Pythona 3.0 udało się to osiągnąć. W Pythonie 3.5 wprowadzono funkcje, które usprawniają proces przejścia i zapewniają, że ta sama baza kodu działa zarówno w Pythonie 2, jak i Pythonie 3.
Źródło: opennet.ru