.NET 용 Python이 죽음에서 떠오르다

.Net 프레임 워크의 CLR (공용 언어 런타임)에서 실행되는 Python 구현 인 IronPython에 대한 개발은 최근 프로젝트가 새로운 개발 리더로 손을 바꾼 덕분에 팔에 맞서고 있습니다.

전 IronPython 개발자 인 Jeff Hardy는 이달 초 Ironpython-users 메일 링리스트에서 전환을 확인했습니다. Hardy는 "여러 가지 이유로 IronPython에 당장 주목할 시간이 없습니다. 그래서 프로젝트의 제어권을 [동료 프로젝트 기여자] Alex Earl과 Benedikt Eggers에게 넘깁니다."

.Net 용 Python 및 그 반대

C #으로 작성된 IronPython은 단순히 기본 Python 프로그램을 실행하기위한 것이 아닙니다. Python 프로그래머에게 기존 .Net 애플리케이션 및 객체에 대한 브리지를 제공 할 수 있습니다. 무엇보다도 이러한 객체는 네이티브 Python 객체와 동일한 구문 및 관용구로 가져 와서 처리 할 수 ​​있습니다.

IronPython의 개발은 지난 몇 년 동안 의심 할 여지없이 느려졌습니다. 마지막 주요 릴리스는 2014 년 말에 Python 2.7.5 용이었습니다. Python 3은 IronPython에서 지원되지 않았습니다. Python 2가 2020 년부터 더 이상 지원되지 않고 Python 3이 확립 된 후속 버전이기 때문에 주요 단점입니다.

개발자 채팅 사이트 Gitter, Earl, Eggers 등의 회의에서 프로젝트가 진행되면서 직면 한 가장 시급한 문제를 해시했습니다. CodePlex의 뛰어난 IronPython 문제에 대해 어떻게해야할까요? 구현할 릴리스 일정의 종류 IronPython 3을 위해 어떤 종류의 로드맵을 고안해야할까요?

토론에서 나온 또 다른 문제는 C 확장을 사용하는 Python 라이브러리에 대한 지원을 구현하는 방법이었습니다. IronPython이 가능한 가장 광범위한 청중을 확보하려면 이것은 선택 사항이 아닙니다. Numpy와 같은 많은 주요 Python 라이브러리는 속도를 위해 C 확장을 사용하며, 재 컴파일 할 필요없이 IronPython에서있는 그대로 작동하는 것이 이상적입니다.

좋은 소식은 컴파일 된 CPython 확장이 IronPython에서있는 그대로 작동 할 수 있도록 고안된 프로젝트 인 Ironclad라는이 영역에서 이미 일부 작업이 수행되었다는 것입니다. 나쁜 소식은 프로젝트가 오랜 시간 동안 많은 작업을 보지 못했고 최신 Python에 유용하도록 크게 수정해야한다는 것입니다.

루비와 GIL

또 다른 문제는 동일한 팀이 처리하는 유사한 프로젝트를 처리하는 방법이었습니다. 이름에서 알 수 있듯이 Ruby의 .Net 구현 인 IronRuby입니다. 두 언어는 Microsoft 내에서 Dynamic Language Runtime에 대한 동일한 노력에서 비롯 되었기 때문에 공동 개발되었으며 Microsoft가 2010 년에 커뮤니티 중심의 노력으로 분리 한 후에도 밀접하게 유지되었습니다.

계획은 IronRuby 자체 프로젝트를 자체 개발자 청중을 유치하는 것입니다. IronPython 2는 개별 프로젝트로 계속 개발 될 것입니다.

미래의 IronPython 개발은 빠르고 멀티 코어 친화적 인 Python 런타임에 대한 오랜 꿈을 실현하는 방법을 제공함으로써 유익 할 것입니다. IronPython에는 고성능에 대한 장벽으로 비난 받아온 많은 Python 구현 기능인 GIL (Global Interpreter Lock)이 없습니다.

즉, IronPython에 GIL이 없다고해서 자동으로 속도가 빨라지는 것은 아닙니다. 일부 IronPython 벤치 마크는 CPython보다 우수하지만 다른 벤치 마크는 현저히 나쁩니다. 현재로서는 IronPython을 Python의 현재 브랜치 (2 및 3)에서 속도를 높이는 것만으로도 충분한 임무를 수행해야합니다.