4만 줄의 Python 코드를 유형 검사하는 경로입니다. 2 부

오늘 우리는 Dropbox가 수백만 줄의 Python 코드에 대한 유형 제어를 어떻게 구성했는지에 대한 자료 번역의 두 번째 부분을 게시합니다.

→ XNUMX부 읽기

공식 유형 지원(PEP 484)

우리는 Hack Week 2014 동안 Dropbox에서 mypy에 대한 첫 번째 진지한 실험을 수행했습니다. Hack Week는 Dropbox가 주최하는 XNUMX주일 이벤트입니다. 이 기간 동안 직원들은 원하는 것은 무엇이든 일할 수 있습니다! Dropbox의 가장 유명한 기술 프로젝트 중 일부는 이와 같은 행사에서 시작되었습니다. 이 실험의 결과로 우리는 mypy가 아직 널리 사용될 준비가 되어 있지는 않지만 유망해 보인다는 결론을 내렸습니다.

당시에는 Python 유형 힌트 시스템을 표준화하려는 아이디어가 떠돌았습니다. 내가 말했듯이 Python 3.0부터 함수에 유형 주석을 사용할 수 있었지만 이는 정의된 구문과 의미가 없는 임의의 표현식일 뿐입니다. 프로그램 실행 중에 이러한 주석은 대부분 무시되었습니다. Hack Week 이후 우리는 의미 체계 표준화 작업을 시작했습니다. 이 작품이 등장하게 된 계기가 되었습니다 펩 484 (Guido van Rossum, Łukasz Langa와 나는 이 문서에 협력했습니다).

우리의 동기는 두 가지 측면에서 볼 수 있습니다. 첫째, 우리는 전체 Python 생태계가 유형 힌트(Python에서 "유형 주석"과 동일하게 사용되는 용어) 사용에 대한 공통 접근 방식을 채택할 수 있기를 바랐습니다. 가능한 위험을 고려하면 이는 상호 호환되지 않는 많은 접근 방식을 사용하는 것보다 낫습니다. 둘째, 우리는 Python 커뮤니티의 많은 구성원과 형식 주석 메커니즘을 공개적으로 논의하고 싶었습니다. 이러한 욕구는 우리가 광범위한 Python 프로그래머 대중의 눈에 언어의 기본 아이디어에서 "배교자"처럼 보이고 싶지 않다는 사실에 부분적으로 영향을 받았습니다. 이는 "오리 타이핑"으로 알려진 동적 유형 언어입니다. 커뮤니티에서는 처음부터 정적 타이핑 아이디어에 대해 다소 의심스러운 태도가 나타날 수밖에 없었습니다. 그러나 정적 타이핑이 필수가 아니라는 것이 분명해진 후(그리고 사람들이 그것이 실제로 유용하다는 것을 깨달은 후) 그 정서는 결국 약해졌습니다.

결국 채택된 유형 힌트 구문은 당시 mypy가 지원했던 것과 매우 유사했습니다. PEP 484는 3.5년 Python 2015와 함께 출시되었습니다. Python은 더 이상 동적으로 입력되는 언어가 아닙니다. 나는 이 사건을 파이썬 역사에 있어서 중요한 이정표로 생각하고 싶습니다.

마이그레이션 시작

2015년 말, Dropbox는 mypy 작업을 위해 XNUMX명으로 구성된 팀을 구성했습니다. 여기에는 귀도 반 로섬(Guido van Rossum), 그렉 프라이스(Greg Price), 데이비드 피셔(David Fisher)가 포함되었습니다. 그 순간부터 상황은 매우 빠르게 발전하기 시작했습니다. mypy 성장의 첫 번째 장애물은 성능이었습니다. 위에서 암시했듯이 프로젝트 초기에는 mypy 구현을 C로 변환하는 것을 고려했지만 이 아이디어는 현재 목록에서 제외되었습니다. 우리는 mypy와 같은 도구에 비해 충분히 빠르지 않은 CPython 인터프리터를 사용하여 시스템을 실행하는 데 어려움을 겪었습니다. (JIT 컴파일러를 사용한 대체 Python 구현인 PyPy 프로젝트도 우리에게 도움이 되지 않았습니다.)

다행스럽게도 일부 알고리즘 개선이 여기에 도움이 되었습니다. 최초의 강력한 "가속기"는 증분 검사 구현이었습니다. 이 개선의 이면에 있는 아이디어는 간단했습니다. 이전 mypy 실행 이후 모든 모듈의 종속성이 변경되지 않은 경우 종속성을 작업하는 동안 이전 실행 중에 캐시된 데이터를 사용할 수 있습니다. 수정된 파일과 이에 종속된 파일에 대해서만 유형 검사를 수행하면 되었습니다. Mypy는 조금 더 나아갔습니다. 모듈의 외부 인터페이스가 변경되지 않은 경우 mypy는 이 모듈을 가져온 다른 모듈을 다시 확인할 필요가 없다고 가정했습니다.

증분 검사는 대량의 기존 코드에 주석을 달 때 많은 도움이 되었습니다. 요점은 주석이 점진적으로 코드에 추가되고 점진적으로 개선됨에 따라 이 프로세스에는 일반적으로 mypy의 많은 반복 실행이 포함된다는 것입니다. mypy의 첫 번째 실행은 확인할 종속성이 많았기 때문에 여전히 매우 느렸습니다. 그런 다음 상황을 개선하기 위해 원격 캐싱 메커니즘을 구현했습니다. mypy가 로컬 캐시가 오래되었을 가능성이 있음을 감지하면 중앙 저장소에서 전체 코드베이스에 대한 현재 캐시 스냅샷을 다운로드합니다. 그런 다음 이 스냅샷을 사용하여 증분 검사를 수행합니다. 이는 mypy의 성능 향상을 향한 또 하나의 큰 발걸음을 내디뎠습니다.

이는 Dropbox에서 유형 검사가 빠르고 자연스럽게 채택된 시기였습니다. 2016년 말까지 우리는 이미 유형 주석이 포함된 약 420000줄의 Python 코드를 보유했습니다. 많은 사용자가 유형 검사에 열광했습니다. 점점 더 많은 개발팀이 Dropbox mypy를 사용하고 있었습니다.

그 당시에는 모든 것이 괜찮아 보였지만 여전히 해야 할 일이 많았습니다. 우리는 프로젝트의 문제 영역을 파악하고 먼저 해결해야 할 문제가 무엇인지 이해하기 위해 정기적인 내부 사용자 설문 조사를 수행하기 시작했습니다(이 관행은 오늘날에도 회사에서 여전히 사용됩니다). 가장 중요한 것은 두 가지 작업이었습니다. 첫째, 코드의 더 많은 유형 범위가 필요했고, 둘째, 더 빠르게 작동하려면 mypy가 필요했습니다. mypy의 속도를 높이고 이를 회사 프로젝트에 구현하기 위한 작업이 아직 완료되지 않았다는 것은 분명했습니다. 우리는 이 두 가지 과제의 중요성을 충분히 인식하고 이를 해결하기 시작했습니다.

생산성이 향상됩니다!

증분 검사를 통해 mypy가 더 빨라졌지만 도구는 여전히 충분히 빠르지 않았습니다. 많은 증분 검사가 약 XNUMX분 동안 지속되었습니다. 그 이유는 주기적 수입 때문이었습니다. 이는 아마도 Python으로 작성된 대규모 코드베이스로 작업해 본 사람이라면 놀랄 일이 아닐 것입니다. 우리는 수백 개의 모듈 세트를 갖고 있었고, 각 모듈은 다른 모든 모듈을 간접적으로 가져왔습니다. 가져오기 루프의 파일이 변경된 경우 mypy는 해당 루프의 모든 파일과 종종 해당 루프에서 모듈을 가져온 모든 모듈을 처리해야 했습니다. 그러한 악순환 중 하나는 Dropbox에서 많은 문제를 일으킨 악명 높은 “의존성 얽힘”이었습니다. 이 구조에는 수백 개의 모듈이 포함되어 있었고 직접 또는 간접적으로 많은 테스트를 가져오는 동안 프로덕션 코드에도 사용되었습니다.

우리는 순환 종속성을 "풀 수 있는" 가능성을 고려했지만 이를 수행할 리소스가 없었습니다. 우리에게 익숙하지 않은 코드가 너무 많았습니다. 그 결과 우리는 대안적인 접근 방식을 생각해 냈습니다. 우리는 "의존성 엉킴"이 있는 경우에도 mypy가 빠르게 작동하도록 하기로 결정했습니다. 우리는 mypy 데몬을 사용하여 이 목표를 달성했습니다. 데몬은 두 가지 흥미로운 기능을 구현하는 서버 프로세스입니다. 첫째, 전체 코드베이스에 대한 정보를 메모리에 저장합니다. 이는 mypy를 실행할 때마다 가져온 수천 개의 종속성과 관련된 캐시된 데이터를 로드할 필요가 없음을 의미합니다. 둘째, 그는 작은 구조 단위 수준에서 기능과 다른 개체 간의 종속성을 주의 깊게 분석합니다. 예를 들어, 함수가 foo 함수를 호출하다 bar, 그러면 의존성이 있습니다 foo 부터 bar. 파일이 변경되면 데몬은 먼저 변경된 파일만 격리하여 처리합니다. 그런 다음 변경된 함수 서명과 같이 해당 파일에 대해 외부에서 볼 수 있는 변경 사항을 살펴봅니다. 데몬은 수정된 기능을 실제로 사용하는 기능을 다시 확인하기 위해서만 가져오기에 대한 자세한 정보를 사용합니다. 일반적으로 이 접근 방식을 사용하면 검사해야 하는 기능이 거의 없습니다.

원래 mypy 구현은 한 번에 하나의 파일을 처리하는 데 중점을 두었기 때문에 이 모든 것을 구현하는 것은 쉽지 않았습니다. 우리는 코드에서 무언가 변경된 경우 반복적인 확인이 필요한 여러 경계선 상황을 처리해야 했습니다. 예를 들어, 클래스에 새 기본 클래스가 할당되면 이런 일이 발생합니다. 원하는 대로 작업을 수행한 후에는 대부분의 증분 검사 실행 시간을 단 몇 초로 줄일 수 있었습니다. 이것은 우리에게 큰 승리처럼 보였습니다.

생산성이 더욱 향상됩니다!

위에서 논의한 원격 캐싱과 함께 mypy 데몬은 프로그래머가 자주 유형 검사를 실행하여 소수의 파일을 변경할 때 발생하는 문제를 거의 완벽하게 해결했습니다. 그러나 가장 불리한 사용 사례의 시스템 성능은 여전히 ​​최적과는 거리가 멀었습니다. mypy를 깨끗하게 시작하는 데 15분 이상이 걸릴 수 있습니다. 그리고 이것은 우리가 만족했던 것보다 훨씬 더 많은 일이었습니다. 프로그래머들이 계속해서 새로운 코드를 작성하고 기존 코드에 주석을 추가함에 따라 매주 상황은 더욱 악화되었습니다. 우리 사용자들은 여전히 ​​더 나은 성능을 원하고 있지만 중간에 만나서 기뻤습니다.

우리는 mypy에 관한 이전 아이디어 중 하나로 돌아가기로 결정했습니다. 즉, Python 코드를 C 코드로 변환하는 것입니다. Cython(Python으로 작성된 코드를 C 코드로 변환할 수 있는 시스템)을 사용해 실험해도 눈에 띄는 속도 향상이 없었기 때문에 자체 컴파일러를 작성한다는 아이디어를 되살리기로 결정했습니다. mypy 코드베이스(Python으로 작성됨)에는 이미 필요한 모든 유형 주석이 포함되어 있으므로 이러한 주석을 사용하여 시스템 속도를 높이는 것이 가치 있다고 생각했습니다. 나는 이 아이디어를 테스트하기 위해 신속하게 프로토타입을 만들었습니다. 다양한 마이크로 벤치마크에서 10배 이상의 성능 향상을 보여주었습니다. 우리의 아이디어는 Cython을 사용하여 Python 모듈을 C 모듈로 컴파일하고 유형 주석을 런타임 유형 검사로 바꾸는 것이었습니다(일반적으로 유형 주석은 런타임 시 무시되고 유형 검사 시스템에서만 사용됩니다). 우리는 실제로 Python의 mypy 구현을 정적으로 입력되도록 설계된 언어로 변환할 계획을 세웠는데, 이 언어는 Python과 똑같아 보이고 대부분 작동합니다. (이런 종류의 언어 간 마이그레이션은 mypy 프로젝트의 전통이 되었습니다. 원래 mypy 구현은 Alore로 작성되었으며 Java와 Python의 구문 하이브리드가 있었습니다.)

CPython 확장 API에 집중하는 것이 프로젝트 관리 기능을 잃지 않는 핵심이었습니다. mypy에 필요한 가상 머신이나 라이브러리를 구현할 필요가 없었습니다. 또한 전체 Python 생태계와 모든 도구(예: pytest)에 계속 액세스할 수 있습니다. 이는 개발 중에 해석된 Python 코드를 계속 사용할 수 있다는 것을 의미하며, 코드가 컴파일될 때까지 기다리지 않고 코드를 변경하고 테스트하는 매우 빠른 패턴으로 계속 작업할 수 있음을 의미합니다. 말하자면 우리는 두 개의 의자에 앉아 일을 훌륭하게 수행하는 것처럼 보였고 우리는 그것을 좋아했습니다.

우리가 mypyc라고 부르는 컴파일러(유형 분석을 위한 프런트 엔드로 mypy를 사용하기 때문에)는 매우 성공적인 프로젝트로 판명되었습니다. 전반적으로 우리는 캐싱 없이 빈번한 mypy 실행에 대해 약 4배의 속도 향상을 달성했습니다. mypyc 프로젝트의 핵심을 개발하는 데에는 Michael Sullivan, Ivan Levkivsky, Hugh Hahn 및 나로 구성된 소규모 팀이 약 4개월이 걸렸습니다. 이 작업량은 예를 들어 C++ 또는 Go에서 mypy를 다시 작성하는 데 필요한 작업량보다 훨씬 적습니다. 그리고 프로젝트를 다른 언어로 다시 작성할 때보다 훨씬 적은 수의 변경 작업을 수행해야 했습니다. 또한 우리는 mypyc을 다른 Dropbox 프로그래머들이 mypyc을 사용하여 코드를 컴파일하고 속도를 높일 수 있는 수준으로 끌어올릴 수 있기를 바랐습니다.

이러한 수준의 성능을 달성하기 위해 우리는 몇 가지 흥미로운 엔지니어링 솔루션을 적용해야 했습니다. 따라서 컴파일러는 빠르고 낮은 수준의 C 구문을 사용하여 많은 작업 속도를 높일 수 있습니다. 예를 들어, 컴파일된 함수 호출은 C 함수 호출로 변환됩니다. 그리고 그러한 호출은 해석된 함수를 호출하는 것보다 훨씬 빠릅니다. 사전 조회와 같은 일부 작업에는 여전히 CPython의 일반 C-API 호출이 포함되어 있으며 컴파일 시 속도가 약간 더 빨라졌습니다. 해석으로 인해 발생하는 시스템의 추가 부하를 제거할 수 있었지만 이 경우에는 성능 측면에서 약간의 이득만 얻었습니다.

가장 일반적인 "느린" 작업을 식별하기 위해 코드 프로파일링을 수행했습니다. 이 데이터로 무장하여 우리는 mypyc를 조정하여 해당 작업에 대해 더 빠른 C 코드를 생성하거나 더 빠른 작업을 사용하여 해당 Python 코드를 다시 작성하려고 했습니다(때때로 해당 문제나 다른 문제에 대한 충분히 간단한 솔루션이 없었습니다). . Python 코드를 다시 작성하는 것이 컴파일러가 자동으로 동일한 변환을 수행하도록 하는 것보다 문제에 대한 더 쉬운 해결책인 경우가 많습니다. 장기적으로 우리는 이러한 변환 중 많은 부분을 자동화하고 싶었지만 당시에는 최소한의 노력으로 mypy 속도를 높이는 데 중점을 두었습니다. 그리고 우리는 이 목표를 향해 나아가면서 여러 모퉁이를 잘라냈습니다.

계속 될 ...

독자 여러분! mypy 프로젝트가 존재한다는 사실을 알았을 때 그에 대한 인상은 어땠나요?

출처 : habr.com