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

Python 코드에 대한 유형 검사 시스템을 구현할 때 Dropbox가 취한 경로에 대한 자료 번역의 세 번째 부분을 여러분께 소개합니다.

→ 이전 부분: 처음으로 и 초

4만 줄의 입력 코드 도달

또 다른 주요 과제이자 내부 설문 조사에서 두 번째로 가장 일반적인 관심사는 Dropbox에서 유형 검사에 포함되는 코드의 양을 늘리는 것이었습니다. 우리는 이 문제를 해결하기 위해 형식화된 코드베이스의 크기를 자연스럽게 늘리는 것부터 mypy 팀의 노력을 정적 및 동적 자동 유형 추론에 집중하는 것까지 여러 가지 접근 방식을 시도했습니다. 결국 단순한 승리 전략은 없는 것 같았지만, 여러 접근 방식을 결합해 주석 코드 양의 급속한 성장을 이룰 수 있었습니다.

결과적으로 우리의 가장 큰 Python 저장소(백엔드 코드 포함)에는 주석이 달린 코드가 거의 4만 줄에 달합니다. 정적 코드 타이핑 작업은 약 XNUMX년 만에 완료되었습니다. Mypy는 이제 입력 진행 상황을 더 쉽게 모니터링할 수 있는 다양한 유형의 코드 범위 보고서를 지원합니다. 특히 유형의 명시적인 사용과 같이 유형이 모호한 코드에 대한 보고서를 생성할 수 있습니다. Any 확인할 수 없는 주석 또는 유형 주석이 없는 타사 라이브러리를 가져오는 등의 경우. Dropbox의 유형 검사 정확성을 향상시키는 프로젝트의 일환으로 우리는 중앙 집중식 Python 저장소에 있는 일부 인기 오픈 소스 라이브러리의 유형 정의(소위 스텁 파일)를 개선하는 데 기여했습니다. 타자기.

우리는 일부 특정 Python 패턴에 대해 보다 정확한 유형을 허용하는 유형 시스템의 새로운 기능을 구현(및 후속 PEP에서 표준화)했습니다. 이에 대한 주목할만한 예는 TypeDict이는 각각 고유한 유형의 값을 갖는 고정된 문자열 키 세트가 있는 JSON과 유사한 사전에 대한 유형을 제공합니다. 우리는 계속해서 유형 시스템을 확장할 예정입니다. 다음 단계는 Python의 수치 기능에 대한 지원을 개선하는 것입니다.

주석이 달린 코드 줄 수: 서버

주석이 달린 코드 줄 수: 클라이언트

주석이 달린 코드의 총 줄 수

Dropbox에서 주석이 추가된 코드의 양을 늘리기 위해 수행한 작업의 주요 기능에 대한 개요는 다음과 같습니다.

주석 엄격함. 우리는 새로운 코드에 주석을 추가하는 데 대한 요구 사항을 점차적으로 강화했습니다. 우리는 이미 일부 주석이 있는 파일에 주석 추가를 제안하는 Linter 팁부터 시작했습니다. 이제 새 Python 파일과 대부분의 기존 파일에 유형 주석이 필요합니다.

보고서를 입력합니다. 우리는 팀의 코드 입력 수준에 대한 주간 보고서를 보내고 무엇에 먼저 주석을 달아야 하는지에 대한 조언을 제공합니다.

마이피의 대중화. 우리는 이벤트에서 mypy에 대해 이야기하고 팀과 대화하여 유형 주석을 시작하는 데 도움을 줍니다.

투표소. 당사는 주요 문제점을 파악하기 위해 정기적인 사용자 설문조사를 실시합니다. 우리는 이러한 문제를 해결하기 위해 상당한 노력을 기울일 준비가 되어 있습니다(mypy 속도를 높이기 위해 새로운 언어를 만드는 것까지!).

성능. 데몬과 mypyc를 사용하여 mypy의 성능을 크게 향상시켰습니다. 이는 Annotation 과정에서 발생하는 불편함을 해소하고, 많은 양의 코드 작업이 가능하도록 하기 위함이었습니다.

편집자와의 통합. Dropbox에서 널리 사용되는 편집기에서 mypy 실행을 지원하는 도구를 만들었습니다. 여기에는 PyCharm, Vim 및 VS Code가 포함됩니다. 이를 통해 코드에 주석을 달고 기능을 확인하는 프로세스가 크게 단순화되었습니다. 이러한 유형의 작업은 기존 코드에 주석을 달 때 일반적입니다.

정적 분석. 우리는 정적 분석 도구를 사용하여 함수 서명을 추론하는 도구를 만들었습니다. 이 도구는 상대적으로 간단한 상황에서만 작동할 수 있지만 많은 노력 없이도 코드 유형 적용 범위를 늘리는 데 도움이 되었습니다.

타사 라이브러리를 지원합니다. 우리 프로젝트의 대부분은 SQLAlchemy 툴킷을 사용합니다. PEP 484 유형이 직접 모델링할 수 없는 Python의 동적 기능을 활용합니다. 우리는 PEP 561에 따라 해당 스텁 파일을 생성하고 mypy용 플러그인을 작성했습니다(오픈 소스), 이는 SQLAlchemy 지원을 향상시킵니다.

우리가 겪은 어려움

4만 줄의 입력된 코드를 작성하는 과정이 항상 쉬운 것은 아니었습니다. 이 길에서 우리는 많은 움푹 들어간 곳을 만났고 몇 가지 실수를 저질렀습니다. 이것이 우리가 직면한 몇 가지 문제입니다. 우리는 이에 대해 이야기하는 것이 다른 사람들이 비슷한 문제를 피하는 데 도움이 되기를 바랍니다.

파일이 없습니다. 우리는 아주 적은 양의 파일만을 확인하는 것으로 작업을 시작했습니다. 이 파일에 포함되지 않은 항목은 확인되지 않았습니다. 첫 번째 주석이 나타날 때 파일이 검색 목록에 추가되었습니다. 검증 범위 외부에 있는 모듈에서 무언가를 가져온 경우 다음과 같은 값으로 작업하는 것에 대해 이야기했습니다. Any, 전혀 테스트되지 않았습니다. 이로 인해 특히 마이그레이션 초기 단계에서 입력 정확도가 크게 저하되었습니다. 일반적인 상황은 검토 범위에 파일을 추가하면 코드베이스의 다른 부분에서 문제가 드러나는 것이지만 이 접근 방식은 지금까지 놀랍도록 잘 작동했습니다. 최악의 경우, 서로 독립적으로 유형이 이미 검사된 두 개의 격리된 코드 영역이 병합되었을 때 이러한 영역의 유형이 서로 호환되지 않는 것으로 나타났습니다. 이로 인해 주석을 많이 변경해야 했습니다. 지금 돌이켜보면 우리는 mypy의 유형 검사 영역에 핵심 라이브러리 모듈을 더 빨리 추가했어야 했다는 것을 깨달았습니다. 이렇게 하면 우리 작업이 훨씬 더 예측 가능해집니다.

오래된 코드에 주석을 답니다. 우리가 시작했을 때 기존 Python 코드는 약 4만 줄이었습니다. 이 모든 코드에 주석을 다는 것이 쉬운 일이 아니라는 것은 분명했습니다. 우리는 테스트가 실행될 때 유형 정보를 수집하고 수집된 정보를 기반으로 코드에 유형 주석을 추가할 수 있는 PyAnnotate라는 도구를 만들었습니다. 그러나 우리는 이 도구가 특별히 널리 채택되는 것을 발견하지 못했습니다. 유형 정보 수집 속도가 느렸고, 자동으로 생성된 주석을 수동으로 편집해야 하는 경우가 많았습니다. 우리는 코드를 검토할 때마다 이 도구를 자동으로 실행하거나 실제 네트워크 요청의 소량 분석을 기반으로 유형 정보를 수집하는 방법을 고려했지만 두 가지 접근 방식 중 하나가 너무 위험했기 때문에 사용하지 않기로 결정했습니다.

결과적으로 대부분의 코드는 소유자가 수동으로 주석을 추가했음을 알 수 있습니다. 이 프로세스를 올바른 방향으로 안내하기 위해 주석을 달아야 하는 특히 중요한 모듈과 기능에 대한 보고서를 준비합니다. 예를 들어, 수백 곳에서 사용되는 라이브러리 모듈에 대한 유형 주석을 제공하는 것이 중요합니다. 하지만 새로운 서비스로 교체되는 기존 서비스에는 주석을 추가하는 것이 더 이상 중요하지 않습니다. 또한 우리는 레거시 코드에 대한 유형 주석을 생성하기 위해 정적 분석을 사용하는 방법을 실험하고 있습니다.

주기적 수입. 위에서 나는 mypy의 속도를 높이는 것을 어렵게 만드는 순환 가져오기("종속성 엉킴")에 대해 이야기했습니다. 우리는 또한 mypy가 이러한 순환 가져오기로 인해 발생하는 모든 종류의 관용어를 지원하도록 열심히 노력해야 했습니다. 우리는 최근 순환 가져오기와 관련된 대부분의 mypy 문제를 해결하는 주요 시스템 재설계 프로젝트를 완료했습니다. 이러한 문제는 실제로 프로젝트 초기부터 발생했습니다. 즉, mypy 프로젝트가 원래 중점을 두었던 교육 언어인 Alore에서 비롯되었습니다. Alore 구문을 사용하면 순환 가져오기 명령 관련 문제를 쉽게 해결할 수 있습니다. 최신 mypy는 이전의 단순한 구현(Alore에 매우 적합함)에서 몇 가지 제한 사항을 물려받았습니다. Python에서는 표현식이 모호하기 때문에 순환 가져오기 작업을 어렵게 만듭니다. 예를 들어 할당 작업은 실제로 유형 별칭을 정의할 수 있습니다. 대부분의 가져오기 루프가 처리될 때까지 Mypy가 항상 이와 같은 것을 감지할 수 있는 것은 아닙니다. Alore에는 그러한 모호함이 없었습니다. 시스템 개발 초기 단계에서 내린 잘못된 결정은 수년 후 프로그래머에게 불쾌한 놀라움을 선사할 수 있습니다.

결과: 5만 줄의 코드와 새로운 지평을 향한 길

mypy 프로젝트는 초기 프로토타입부터 4만 라인의 생산 코드 유형을 제어하는 ​​시스템에 이르기까지 먼 길을 걸어왔습니다. mypy가 발전하면서 Python의 유형 힌트가 표준화되었습니다. 요즘 Python 코드 입력을 중심으로 강력한 생태계가 개발되었습니다. 여기에는 라이브러리 지원 공간이 있고, IDE 및 편집기를 위한 보조 도구가 포함되어 있으며, 각각 장단점이 있는 여러 유형 제어 시스템이 있습니다.

Dropbox에서는 유형 검사가 이미 제공되고 있지만 아직은 Python 코드를 입력하는 초기 단계에 있다고 생각합니다. 유형 검사 기술은 계속 발전하고 개선될 것이라고 생각합니다.

대규모 Python 프로젝트에서 유형 검사를 아직 사용하지 않았다면 지금이 정적 유형 지정으로 전환하기 가장 좋은 시기라는 점을 알아 두십시오. 나는 비슷한 전환을 한 사람들과 이야기를 나눴습니다. 그들 중 누구도 그것을 후회하지 않았습니다. 유형 검사를 통해 Python은 "일반 Python"보다 대규모 프로젝트를 개발하는 데 훨씬 더 적합한 언어입니다.

독자 여러분! Python 프로젝트에서 유형 검사를 사용합니까?

출처 : habr.com