원문: Formalizing the AST Change Control Policy (날짜: 2011-04-06, 작성자: Paul Moore)
파이썬은 AST 모듈을 통하여 파이썬 소스 코드의 컴파일된 형태를 나타내는 추상 구문 트리(AST)를 제공합니다. 사용자는 AST 모듈을 사용하여 소스 코드의 파싱과 바이트 코드의 컴파일 사이에 있는 AST 표현을 살펴보고 다룰 수 있습니다.
파이썬 코드의 의미는 언어 레퍼런스에 따라 정의되지만, AST 모듈은 CPython 구현의 세부 사항에 해당하므로 다른 파이썬 구현이 따라야 할 필요는 없습니다.
AST의 호환성
Eugene Toder는 CPython의 피프홀(peephole) 최적화를 AST에 적용하도록 (현재는 바이트 코드에서 이루어지는 것을) 재작성하는 작업 중에 AST의 구조를 조금 바꿀 필요가 있었습니다. CPython 세부 구현인 AST에는 어떤 하위 호환성 정책을 적용해야 하는지는 바로 명확하지가 않았습니다. 그래서 Eugene은 python-dev에 질문을 했습니다. AST를 변경할 때 하위 호환성을 보장할 필요가 있나요?
일반적인 의견은 호환성은 필요하지 않다는 것이었습니다. AST 모듈은 ast.__version__ 상수를 제공하는데, 사용자 코드는 이를 통해 AST의 버전에 따라 동작을 다양화할 수 있습니다. 구현에 종속적인 모듈에는 이것만으로도 충분히 호환성을 갖춘 것으로 보았습니다.
다른 파이썬 구현들
사실 실제로 Jython과 IronPython 개발자들도 각자의 구현에 CPython과 호환되는 AST 모듈이 이미 있거나 제공할 의향이 있다고 말했습니다. 그렇기는 하지만 그것 때문에 AST가 동결되어야(frozen) 한다고 한 것은 아니고 ast.__version__ 상수가 바뀌기만 한다면 괜찮다고 했습니다. 따라서 AST는 호환되지 않는 방식으로 바뀌는 것도 가능할 것입니다.
한가지 test_ast.py에 완벽한 세트의 테스트가 있다면 다른 구현이 CPython의 AST 구현과 호환 가능함을 보장하는 데 도움이 될 것이라는 말이 있었습니다. 파이썬의 내부에 참여하고 싶은 사람에게는 test_ast.py의 커버리지를 넓히는 것이 좋은 프로젝트가 될 것 같습니다.
앞으로 무슨 일이 일어날까요?
토론이 시작됐던 패치는 아직 CPython에 포함되지 않았습니다. 그래서 아마 아무 일도 일어나진 않을 것입니다. 그러나 그 패치가 커밋된다면, AST는 호환되지 않는 방식으로 바뀔 것입니다. ast.__version__ 상수는 이를 반영하여 바뀔 것이고 그래서 사용자 코드도 무엇인가 바뀌었다는 사실을 알 수는 있겠지만, 자신의 코드를 변경할 필요는 있을 것입니다. 일반적으로 앞으로 AST의 변경은 이와 같이 처리될 것입니다.
파이썬 개발자들은 AST가 얼마나 광범위하게 사용되는지, 이번 정책으로 얼마나 영향을 받을지에 관심이 있습니다. 이 변경으로 영향을 받는 코드를 쓰고 계신다면 python-dev의 토론에 참가해주시길 부탁합니다.
댓글 없음:
댓글 쓰기