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

오늘 우리는 Dropbox가 Python 코드의 유형 제어를 처리하는 방법에 대한 자료 번역의 첫 번째 부분을 여러분에게 알려드립니다.

Dropbox는 Python으로 많은 것을 작성합니다. 백엔드 서비스와 데스크톱 클라이언트 애플리케이션 모두에 매우 광범위하게 사용되는 언어입니다. 우리는 또한 Go, TypeScript 및 Rust를 많이 사용하지만 Python이 우리의 주요 언어입니다. 우리의 규모와 수백만 줄의 Python 코드에 대해 이야기하고 있는 것을 고려할 때 그러한 코드의 동적 타이핑이 불필요하게 이해를 복잡하게 만들고 노동 생산성에 심각한 영향을 미치기 시작했다는 것이 밝혀졌습니다. 이 문제를 완화하기 위해 mypy를 사용하여 코드를 정적 유형 검사로 점진적으로 전환하기 시작했습니다. 이것은 아마도 Python에서 가장 널리 사용되는 독립 실행형 유형 검사 시스템일 것입니다. Mypy는 오픈 소스 프로젝트이며 주요 개발자는 Dropbox에서 작업합니다.

Dropbox는 이러한 규모로 Python 코드에 정적 유형 검사를 구현한 최초의 회사 중 하나입니다. Mypy는 요즘 수천 개의 프로젝트에서 사용됩니다. 이 도구는 "전투에서 테스트되었습니다." 우리는 지금의 위치에 도달하기까지 먼 길을 왔습니다. 그 과정에서 많은 실패한 사업과 실패한 실험이 있었습니다. 이 게시물은 내 연구 프로젝트의 일부로 시작된 불안정한 시작부터 Python으로 작성하는 수많은 개발자에게 유형 검사 및 유형 힌트가 일반화되는 현재까지 Python의 정적 유형 검사의 역사를 다룹니다. 이러한 메커니즘은 이제 IDE 및 코드 분석기와 같은 많은 도구에서 지원됩니다.

→ 두 번째 부분을 읽으십시오

유형 검사가 필요한 이유는 무엇입니까?

동적으로 입력되는 Python을 사용해 본 적이 있다면 최근에 정적 입력과 mypy에 대해 왜 그렇게 소란스러운지 혼란스러울 수 있습니다. 또는 동적 타이핑 때문에 Python을 좋아할 수도 있습니다. 정적 타이핑의 가치에 대한 핵심은 솔루션의 규모입니다. 프로젝트가 클수록 정적 타이핑이 더 많이 필요하고 결국 더 많이 필요합니다.

특정 프로젝트가 수만 줄의 크기에 도달했고 여러 프로그래머가 작업하고 있는 것으로 밝혀졌다고 가정합니다. 경험을 바탕으로 비슷한 프로젝트를 살펴보면 코드를 이해하는 것이 개발자의 생산성을 유지하는 열쇠가 될 것이라고 말할 수 있습니다. 유형 주석이 없으면 예를 들어 함수에 전달할 인수 또는 함수가 반환할 수 있는 유형을 파악하기 어려울 수 있습니다. 다음은 유형 주석을 사용하지 않고 대답하기 어려운 일반적인 질문입니다.

• 이 함수가 반환할 수 있습니까? None?
• 이 주장은 무엇이어야 하는가? items?
• 속성 유형은 무엇입니까 id: int 그것은, str, 아니면 사용자 정의 유형?
• 이 인수는 목록이어야 합니까? 튜플을 전달할 수 있습니까?

다음 유형 주석 코드 스니펫을 보고 유사한 질문에 답하려고 하면 이것이 가장 간단한 작업임을 알 수 있습니다.

class Resource:
    id: bytes
    ...
    def read_metadata(self, 
                      items: Sequence[str]) -> Dict[str, MetadataItem]:
        ...

• read_metadata 돌아오지 않는다 None, 반환 유형이 아니기 때문에 Optional[…].
• 논의 items 일련의 라인입니다. 임의로 반복할 수 없습니다.
• 속성 id 바이트 문자열입니다.

이상적인 세계에서는 그러한 모든 미묘함이 내장된 문서(docstring)에 설명되어 있다고 기대할 수 있습니다. 그러나 경험은 이러한 문서가 작업해야 하는 코드에서 종종 관찰되지 않는다는 사실에 대한 많은 예를 제공합니다. 그러한 문서가 코드에 있더라도 절대적인 정확성을 기대할 수는 없습니다. 이 문서는 모호하고 부정확하며 오해의 여지가 있을 수 있습니다. 대규모 팀이나 대규모 프로젝트에서 이 문제는 극도로 심각해질 수 있습니다.

Python은 프로젝트의 초기 또는 중간 단계에서 탁월하지만 어느 시점에서 성공적인 프로젝트와 Python을 사용하는 회사는 "정적으로 유형이 지정된 언어로 모든 것을 다시 작성해야 합니까?"라는 중요한 질문에 직면할 수 있습니다.

mypy와 같은 유형 검사 시스템은 개발자에게 유형을 설명하기 위한 공식 언어를 제공하고 유형 선언이 프로그램 구현과 일치하는지 확인(및 선택적으로 존재 여부를 확인)하여 위의 문제를 해결합니다. 일반적으로 이러한 시스템은 신중하게 확인된 문서와 같은 것을 마음대로 사용할 수 있다고 말할 수 있습니다.

이러한 시스템을 사용하면 다른 이점이 있으며 이미 완전히 사소하지 않습니다.

• 유형 검사 시스템은 약간의 작은(작지 않은) 오류를 감지할 수 있습니다. 전형적인 예는 값을 처리하는 것을 잊어버린 경우입니다. None 또는 다른 특별한 조건.
• 코드 리팩토링은 유형 검사 시스템이 변경해야 하는 코드에 대해 종종 매우 정확하기 때문에 크게 단순화됩니다. 동시에 우리는 테스트로 100% 코드 커버리지를 기대할 필요가 없습니다. 어떤 경우에도 보통은 불가능합니다. 문제의 원인을 찾기 위해 스택 추적의 깊이를 조사할 필요가 없습니다.
• 대규모 프로젝트에서도 mypy는 종종 몇 분의 XNUMX초 만에 전체 유형 검사를 수행할 수 있습니다. 그리고 테스트 실행에는 일반적으로 수십 초 또는 몇 분이 걸립니다. 유형 검사 시스템은 프로그래머에게 즉각적인 피드백을 제공하고 작업을 더 빠르게 수행할 수 있도록 합니다. 그는 더 이상 코드 테스트 결과를 더 빨리 얻기 위해 실제 엔터티를 모의 객체와 패치로 대체하는 깨지기 쉽고 유지 관리하기 어려운 단위 테스트를 작성할 필요가 없습니다.

PyCharm 또는 Visual Studio Code와 같은 IDE 및 편집기는 유형 주석의 기능을 사용하여 개발자에게 코드 완성, 오류 강조 표시 및 일반적으로 사용되는 언어 구성에 대한 지원을 제공합니다. 그리고 이것들은 타이핑의 이점 중 일부에 불과합니다. 일부 프로그래머에게는 이 모든 것이 타이핑을 선호하는 주요 논거입니다. 이것은 구현 직후에 이점이 있는 것입니다. 유형에 대한 이 사용 사례에는 mypy와 같은 별도의 유형 검사 시스템이 필요하지 않지만 mypy는 코드와 유형 주석의 일관성을 유지하는 데 도움이 된다는 점에 유의해야 합니다.

mypy의 배경

mypy의 역사는 제가 Dropbox에 합류하기 몇 년 전 영국 케임브리지에서 시작되었습니다. 저는 박사 과정 연구의 일환으로 정적으로 입력된 언어와 동적 언어의 통합에 참여했습니다. 저는 Jeremy Siek과 Walid Taha의 증분 타이핑에 관한 기사와 Typed Racket 프로젝트에서 영감을 받았습니다. 작은 스크립트에서 수백만 줄로 구성된 코드 베이스에 이르기까지 다양한 프로젝트에 동일한 프로그래밍 언어를 사용하는 방법을 찾으려고 노력했습니다. 동시에 어떤 규모의 프로젝트에서든 너무 큰 타협을 할 필요가 없도록 하고 싶었습니다. 이 모든 것의 중요한 부분은 유형이 지정되지 않은 프로토타입 프로젝트에서 포괄적으로 테스트된 정적으로 유형이 지정된 완제품으로 점진적으로 이동한다는 아이디어였습니다. 요즘은 이런 생각이 당연하게 받아들여지지만 2010년에는 여전히 활발히 탐구되고 있는 문제였다.

유형 검사에 대한 나의 원래 작업은 Python을 대상으로 하지 않았습니다. 대신 작은 "집에서 만든" 언어를 사용했습니다. 알로레. 다음은 우리가 말하는 내용을 이해하는 데 도움이 되는 예입니다(여기서 유형 주석은 선택 사항임).

def Fib(n as Int) as Int
  if n <= 1
    return n
  else
    return Fib(n - 1) + Fib(n - 2)
  end
end

단순화된 모국어를 사용하는 것은 과학 연구에서 사용되는 일반적인 접근 방식입니다. 이는 실험을 신속하게 수행할 수 있게 해주고 연구와 관련이 없는 내용은 쉽게 무시할 수 있기 때문입니다. 실제 프로그래밍 언어는 구현이 복잡한 대규모 현상인 경향이 있으며 이로 인해 실험 속도가 느려집니다. 그러나 단순화된 언어를 기반으로 한 결과는 약간 의심스러워 보입니다. 이러한 결과를 얻는 과정에서 연구자가 언어의 실제 사용에 중요한 고려 사항을 희생했을 수 있기 때문입니다.

Alore에 대한 내 유형 검사기는 매우 유망해 보였지만 Alore로 작성되지 않은 실제 코드를 실험하여 테스트하고 싶었습니다. 다행스럽게도 Alore 언어는 주로 Python과 동일한 아이디어를 기반으로 했습니다. Python의 구문 및 의미 체계와 함께 작동할 수 있도록 typechecker를 다시 만드는 것은 충분히 쉬웠습니다. 이를 통해 오픈 소스 Python 코드에서 유형 검사를 시도할 수 있었습니다. 또한 Alore로 작성된 코드를 Python 코드로 변환하는 트랜스파일러를 작성하고 이를 사용하여 제 타입 체커 코드를 번역했습니다. 이제 저는 Python의 하위 집합, 일종의 언어를 지원하는 Python으로 작성된 유형 검사 시스템을 갖게 되었습니다! (Alore에 적합한 특정 아키텍처 결정은 Python에 적합하지 않았으며 이는 mypy 코드베이스의 일부에서 여전히 눈에 띕니다.)

사실, 내 유형 시스템에서 지원하는 언어는 이 시점에서 Python이라고 부를 수 없었습니다. Python 3 유형 주석 구문의 일부 제한으로 인해 Python의 변형이었습니다.

Java와 Python이 혼합된 것처럼 보였습니다.

int fib(int n):
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

당시 내 아이디어 중 하나는 유형 주석을 사용하여 이러한 종류의 Python을 C 또는 아마도 JVM 바이트코드로 컴파일하여 성능을 개선하는 것이었습니다. 컴파일러 프로토타입을 작성하는 단계에 이르렀지만 유형 검사 자체가 매우 유용해 보였기 때문에 이 아이디어를 포기했습니다.

나는 Santa Clara에서 열린 PyCon 2013에서 내 프로젝트를 발표하게 되었습니다. 나는 또한 자애로운 종신 독재자 귀도 반 로섬과도 이에 대해 이야기했습니다. 그는 내 자신의 구문을 버리고 표준 Python 3 구문을 고수하도록 설득했습니다. Python 3은 함수 주석을 지원하므로 내 예제는 아래와 같이 다시 작성되어 정상적인 Python 프로그램이 될 수 있습니다.

def fib(n: int) -> int:
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

나는 약간의 타협을 해야 했다. 특히 당시 언어의 최신 버전인 Python 3.3은 변수 주석을 지원하지 않았습니다. 나는 이러한 주석의 구문 설계에 대한 다양한 가능성을 전자 메일로 Guido와 논의했습니다. 우리는 변수에 대한 유형 주석을 사용하기로 결정했습니다. 이것은 의도한 목적에 부합했지만 다소 번거로웠습니다(Python 3.6은 더 나은 구문을 제공했습니다).

products = []  # type: List[str]  # Eww

유형 주석은 기본적으로 유형 주석을 지원하지 않는 Python 2를 지원하는 데 유용했습니다.

f fib(n):
    # type: (int) -> int
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

이러한 (및 기타) 상충 관계는 실제로 중요하지 않은 것으로 나타났습니다. 정적 타이핑의 이점은 사용자가 곧 이상적이지 않은 구문을 잊어버렸다는 것을 의미했습니다. 유형 검사 Python 코드에 특별한 구문 구조가 사용되지 않았기 때문에 기존 Python 도구 및 코드 처리 프로세스가 계속 정상적으로 작동하여 개발자가 새 도구를 훨씬 쉽게 배울 수 있습니다.

또한 Guido는 제가 대학원 논문을 마친 후 Dropbox에 합류하도록 설득했습니다. 이것은 mypy 이야기의 가장 흥미로운 부분이 시작되는 곳입니다.

계속 될 ...

독자 여러분! Python을 사용하는 경우 이 언어로 개발하는 프로젝트의 규모에 대해 알려주십시오.

출처 : habr.com