Mercurial을 Python 3으로 마이그레이션하는 데 드는 비용은 예상치 못한 오류가 발생할 수 있습니다.

버전 관리 시스템 관리자 수은제 나를 실망시키다 합계 Python 2에서 Python 3으로 프로젝트를 이전하는 작업을 진행하고 있습니다. 첫 번째 이식 시도가 2008년에 이루어졌고 Python 3 작업을 위한 가속화된 적응이 2015년에 시작되었음에도 불구하고 Python 3을 사용하는 전체 기능은 최신 버전에서만 구현되었습니다. Mercurial 5.2의 분기.

Python 3 포트의 안정성에 대한 예측은 실망스럽습니다. 특히, 테스트가 코드 베이스를 100% 다루지 않고, 정적 분석 중에는 보이지 않고 런타임에만 나타나는 문제가 많기 때문에 몇 년이 지나면 코드에서 무작위 오류가 나타날 것으로 예상됩니다. 또한 많은 타사 추가 기능 및 확장 기능이 Python 3으로 번역되지 않은 상태로 남아 있습니다.
이식 과정에서 Python 3에 대한 지원을 유지하면서 점차적으로 코드를 Python 2에 적용하기로 결정했기 때문에 해당 코드는 Python 2와 3을 결합하기 위한 많은 해킹을 획득했으며, 이는 Python 2 지원이 종료된 후에 정리되어야 합니다.

Python 3의 상황에 대해 언급하면서 Mercurial 관리자는 개발자와 관련된 획기적인 개선이 없는 상황에서 상호 운용성을 깨뜨리는 Python 3을 홍보하고 이를 새롭고 보다 정확한 언어로 강요하기로 한 결정이 큰 실수라고 믿습니다. 이는 지역 사회에 큰 해를 끼치며 대규모 프로젝트에서는 그렇게 할 필요가 없음을 보여주는 예입니다. 점진적으로 기능을 구축하고 애플리케이션을 점진적으로 사용자 정의하는 대신 Python 3의 출시로 인해 개발자는 코드를 다시 작성하고 Python 2와 Python 3에 대한 별도의 분기를 유지 관리하는 데 리소스를 소비해야 했습니다. Python 3.0이 출시된 지 3.5년이 지나서야 Python 2에는 전환 프로세스를 원활하게 하고 동일한 코드 기반이 Python 3와 Python XNUMX을 모두 실행하도록 보장하는 기능이 도입되었습니다.

출처 : opennet.ru