Month: December 2003

원래 파이썬에서 import 하면 모듈이 존재하는 곳을 맨 먼저 찾고, 표준 서치 패스를 찾게 되어있습니다. 그런데, 얼마 전 Raymond의 크리스마스 소원 목록에서 등장해서 엄청난 이슈를 일으키고 있는 명시적 상대 경로 임포트 (explicit relative import)가 이제 뭔가 대세가 되고 있군요.

중간에 문법과 구현 원리가 엄청 많이 제시되기는 했지만, 대충 지금까지의 의견 수렴은

• ‘.’를 기본 sys.path에서 뺌 (지역 디렉토리에서의 단순 임포트 불가)

• from의 패키지명 앞에 . 1개를 쓰는 경우 지역 디렉토리, 2개이상을 쓰는 경우 상위 디렉토리를 찾음.

이렇게 되어가고 있는데, 여기서도 구체적인 문법 모양 등의 사안에 대해서는 의견이 아직 분분하군요. 예를 들면 현재 같은 디렉토리에 있는 파일을 임포트할 때 import what하면 될 게, 이제 앞으로는 from . import what이 된다는.. 상위 디렉토리의 다른 패키지 모듈을 임포트 하는 경우에는 from ..subdir import what 이런식으로 일단은 될 모양이군요. (아직 결정은 안 됨)

이 이외의 의견으로는 이런 것도 있습니다. (다들 나름대로의 지지자들을 확보. )

• 상위 디렉토리에 올라갈 때 .대신 __parent__를 쓰고 현재 디렉토리에서 임포트할 때에는 __here__에서 임포트

• 상위 디렉토리에 올라갈 때 ../../ 식으로 슬래쉬를 넣자는 의견

• 그냥 상대경로 임포트를 놔둔 채로 표준 경로에서 임포트할 때 from stdlib import xxx로 하자는 의견

어떻게 될 지는 며칠 더 토론이 진행되어야 될 것 같습니다.

지난 5월이었던가요.. PyCon에서 Parrot(perl6에 사용될 JIT 지원 VM)팀의 Dan Sugalski가 귀도에게 내년에 패럿기반의 파이썬과 오리지널 CPython간의 벤치마크 시합을 해서 지는 쪽이 맥주를 사고 50달러 내기를 했던 것을 기억하실겁니다.

최근 Dan Sugalski가 이 작업을 위해서 본격적으로 벤치마크할 프로그램의 조건을 구체적으로 얘기를 꺼내기 시작했는데, 대충 파이썬 코어팀과 Dan간의 협의 사항은 이렇게 정해졌네요

• 순수 인터프리터 자체만 테스트하는 것을 목표로 함

• I/O 성능은 테스트하지 않음

• 정규표현식 성능은 테스트하지 않음

• eval과 expr은 테스트하지 않음

• 펜티엄 기반의 리눅스 박스에서 테스트함

• 파이썬 소스가 아닌, 바이트코드를 기반으로 하며 최소한 30초 이상 작동하는 코드로

• 바이트코드는 12월 내에 결정

• 확장 모듈은 사용하지 않고 빌트인 함수는 사용함

귀도는 Parrot이 엄청난 격차로 CPython을 이긴다면, CPython을 버리고 파이썬 기반을 패럿으로 옮겨버릴 수도 있다고 합니다. (과연.. )

며칠 전 Miguel의 블로그에 올라온 블로그가 크게 파장을 일으키고 있네요. Jython 개발자인 Jim Hugunin이 .NET 기반의 새로운 파이썬인 Iron Python을 만들어서 Microsoft 내부 메일링 리스트에 결과를 올렸는데, 예전의 Active State의 구현이나 Parrot계열의 Pirate의 실망스러운 결과와는 완전 상반되게 70%나 CPython보다 빠르다는 결과를 얻었다고 합니다. (원본 메일 (Miguel의 복사본))

IronPython과 CPython, Jython의 벤치마크 (숫자가 낮을 수록 빠름) 

                IronPython-0.1  Python-2.3      Python-2.1      Jython-2.1
pystone         0.58            1.00            1.29            1.61

function call   0.19            1.00            1.12            1.33
integer add     0.59            1.00            1.18            1.08
string.replace  0.92            1.00            1.00            1.40
range(bigint)   5.57            1.00            1.09            16.02
eval("2+2")     66.97           1.00            1.58            91.33

특히나 function call, integer add쪽은 CPython에서 엄청난 오버헤드가 있는 것으로 유명했던 부분이라.. 역시나 IL asm으로 직접 번역하는 것으로 구현된 Iron Python보다 엄청나게 느린 것으로 결과가 나왔군요. 그리고 range의 경우에는 메모리 할당이 단편적으로 엄청나게 일어나기 때문에 CPython이 유리한 게 나왔고 eval(“2+2”)쪽은 CPython은 컴파일러가 순수 C로 구현되어있기 때문에, 흐흐..

하여간 .NET IL asm으로 직접(C# 안 거치고) 파이썬 코드를 번역하면 아무래도 CPython보다 더 빠르지 않을까 생각하던 초기 .NET 개발자들의 예상은 대충 맞았다는 것이 증명되고 있는 듯 합니다. 아직 Iron Python이 많이 구현되지 않은 반면 최적화를 수행하지 않았기 때문에, 앞으로 변동이 좀 있을 것 같기도 한데.. 하여간 무지 기대가 되네요. (MS에 팔아먹으면 대략 낭패 –; )

한편, Iron Python이 오픈소스가 아닌 MS나 다른 회사의 상용 제품으로 들어가는 것을 대비해서 최적화를 계획해야할 텐데, CPython도 이제 슬슬 표준 환경에서의 JIT 지원에 대해서 본격적으로 진지하게 고려해 봐야 할 것 같기도 합니다. (PyPython은 아직 까마득.. 으흐…)