▲

Pyrefly - 파이썬을 위한 새로운 타입 체커 및 IDE 경험

 (engineering.fb.com)
3P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • Meta의 Pyrefly는 Rust로 개발된 오픈 소스 파이썬 타입 체커이자 IDE 확장 기능
  • 초고속 분석 성능과 IDE 통합 기능을 지원하며, Pyre의 한계를 극복하기 위해 개발됨
  • 자동 타입 추론과 대형 코드베이스 지원, 오픈 소스 철학을 원칙으로 삼음
  • 파이썬 커뮤니티와의 협업 및 기여를 통해 생태계 전반의 타입 시스템 개선을 목표로 함
  • 현재 알파 버전 출시, 커뮤니티 피드백과 기여를 적극 요청 중임

소개

  • Pyrefly는 Meta가 Rust로 개발한 파이썬 정적 타입 체커이자 IDE 확장 오픈 소스 프로젝트임
  • 코드 실행 전 타입 일관성 검증을 통해 에러 사전 탐지를 지원함
  • IDE 통합과 CLI 사용 모두 가능하여 유연한 워크플로우를 제공함
  • 오픈 소스 커뮤니티 협업을 통해 파이썬 타입 시스템 및 다양한 라이브러리 발전에 기여 목표임

Pyrefly 개발 배경

  • 2017년, Meta는 Instagram의 대규모 파이썬 코드베이스를 위해 새로운 타입 체커(이후 Pyre)를 개발함
  • Pyre는 Hack, Flow 등의 견고한 설계 참고, 성능을 위해 OCaml로 개발됨
  • 시간이 지나며 타입 시스템 발전 및 IDE 연동 니즈가 커짐에 따라 한계 발생
  • Pyright 등 커뮤니티 툴도 사용하였으나, 대규모 코드 탐색·타입 내보내기 등 요구사항 충족에 한계가 있어 Pyrefly 개발 시도함

Pyrefly의 주요 원칙

  • 1. 성능

    • 개발자는 코드 작성 직후 매 키 입력마다 빠른 타입 체크 필요함
    • Pyrefly는 초대형 코드베이스도 초당 180만 라인 검사가 가능한 고성능 Rust 구현 구조임

  • 2. IDE 중심 설계

    • IDE와 CLI가 동일한 시각을 유지할 수 있도록 처음부터 추상화 설계를 진행함
    • Pyre에서는 사후 보완이었으나, Pyrefly에서는 설계단계부터 일관성을 강조함

  • 3. 인퍼런스(추론)

    • 주석 없이 타입이 명시되지 않은 파이썬 코드도 자동으로 타입 추론 지원
    • 반환값 및 로컬 변수의 타입을 IDE에 표시하고, 더 나은 코드 작성을 위해 더블클릭 시 추론 타입 자동 삽입 가능함

  • 4. 오픈 소스

    • Pyrefly는 MIT 라이선스로 GitHub에서 공개, 커뮤니티 PR 및 이슈 제보 환영
    • 파이썬 생태계와 Meta 주요 라이브러리(PyTorch 등)와 연계하며, Discord 채널 통한 활발한 커뮤니케이션 추구

Pyrefly의 미래

  • 커뮤니티와 함께 파이썬 언어 및 개발자 경험 개선 목표로 활동 중임
  • Pyre 개발 초기부터 코드 오픈소스화 및 PEP 기여 유지, Pyrefly에서도 다양한 개발자·라이브러리·초보자에게 타입 활용 이점 극대화 계획
  • Meta는 동적 언어에서의 타입 활용 경험과 성과를 바탕으로 다양한 경험 공유, 생태계의 타입 품질 향상 추진 예정
  • 현재 Pyrefly는 알파버전이지만, 올 여름 공식 런칭 목표로 지속적인 버그 수정 및 기능 추가 진행 중임
  • 커뮤니티 피드백이 매우 중요하며, Pyrefly 사용 후 이슈 보고 및 개선 요청을 적극 요청함

Pyrefly 알파버전 활용 및 커뮤니티 안내

  • Pyrefly 개발 과정과 기술적 디테일은 Meta Tech Podcast 및 PyCon US 발표 등에서 공개됨
  • Meta Open Source 관련 사이트, YouTube, Facebook, Threads, X, LinkedIn 등 다양한 채널을 통해 추가 소식 제공
▲
GN⁺ 10시간전  [-]
Hacker News 의견
  • Meta의 "Python Language Tooling Team"을 대신해 약간 걱정스러운 마음 형성, uv의 인기가 워낙 높아서 ty가 이 분야에서 승리할 것 같은 예감, 잘못하면 Atom이나 Flow처럼 내부 팀이 외부 오픈 소스에 밀려 위에서 "이 팀 정말 필요 없는 것 아닌가? 오픈 소스로 바꾸자"라는 분위기가 형성되는 상황 발생 가능성, 관리자(Aaron Pollack?)가 신경 써야 할 부분이라고 생각함
    • Kevin, 반갑다는 인사와 함께 과거 Flow에서 일했다는 경험 언급, 지금은 Pyrefly 팀에서 활동 중, 이번에는 Flow와는 다른 접근법을 택했고 오픈 소스 및 커뮤니티 구축을 명확하게 우선순위로 삼았다는 설명, 최근 기업들의 인프라 투자와 관련해 변동성이 컸지만, 현 시점에서 올바른 여정의 시작점에 있다고 믿는다는 생각 공유, 응원의 마음 전달
    • Meta는 특히 개발 도구의 오픈 소스 프로젝트에 대한 통제권을 크게 중요시한다는 의견, 예전에 git 관리자가 monorepo 활용에 대해 지적하며 개선책을 upstream 거부한 일로 mercurial로의 전환이 이루어졌으며, mercurial 쪽은 기꺼이 기여를 받아들였다는 일화, 내부 툴의 변화 속도가 워낙 빠르기 때문에 자체 프로젝트를 소유하는 것이 합리적이라는 설명
    • Facebook에서 나온 것 중 JSX가 가장 마음에 든다는 이야기(아마 유일하게 괜찮다고 생각하는 부분)
  • Meta의 Pyrefly 팀에서 일하고 있다는 소개, FAQ에 많은 질문이 커버되어 있으니 참고 링크 제공, 추가 질문에도 답변 가능하다는 친절함 표시와 관심에 대한 감사 인사
  • 요즘 Rust로 작성된 Python 타입 체커가 세 곳(Microsoft, Facebook, Astral)에서 등장했고, 기존의 mypy도 여전히 존재하는 상황이라는 관찰
    • Microsoft의 타입 체커 Pyright는 Typescript 기반이라는 정정, 그래도 mypy보다 빠르다는 개인적인 경험 공유
    • 모두 정적 타입 체커라는 질문, 런타임용은 없다는 언급
  • 이번이 공식 발표이지만, Pyrefly가 몇 주 전에 이미 논의되었다는 정보 제공, 현재는 알파 단계로 출시 중이며 버그 수정과 기능 개발에 집중해 여름에는 알파 딱지를 떼는 것이 목표라는 팀의 공식 입장 인용
  • 여기 작성된 Rust 코드는 매우 이해하기 쉽지만, 최근 Python 도구가 Rust로 계속 작성되는 것에 대한 우려와 함께 또 다른 N개의 언어 문제 발생 우려감 표시, Mojo가 여기서 뭔가 해줄 수 있길 바라는 마음
    • Python 생태계에서는 Python이 감당할 수 있는 영역에선 Python을 쓰고, 고성능이 필요한 곳에선 Rust나 C 같은 언어를 사용하는 것이 자연스러운 흐름이라고 설명, 결국 N=3(파이썬, 러스트, C), 다만 C는 장기적으로 응용프로그램 프로그래밍에서 서서히 없어져야 한다는 바람, 하지만 실제로는 오랜 시간이 걸릴 전망, 오히려 Python 자체가 레거시가 될 수도 있다는 생각
  • Vim/Neovim에 통합하는 사용법이 안내되고 있어 반갑다는 느낌, 관련 링크 제공
  • Rust로 작성됐다는 점이 왜 큰 장점처럼 언급되는지 의문, 대부분의 사람들이 임베디드 시스템이나 미션 크리티컬 서비스에서 타입 체커를 구동하는 것이 아닌데, "Erlang으로 작성됨"과 비슷한 느낌, 성능이 중요한 코드가 아닌 것은 Python으로 작성하는 편이 더 많은 커뮤니티의 참여와 확장이 가능한데, Rust에 집착하는 이유에 대한 의문
    • Rust 사용 경험 공유, 사용자로서는 속도와 안전성, 개발자 입장에선 기여가 용이하다는 장점 언급, Astral의 매력도 이러한 Rust 기반 툴을 Python에 가져온다는 점이라고 생각, Rust보다 Python을 잘 알지만 Rust 프로젝트에 기여하는 게 더 쉽다고 느낌, Rust품질 도구의 Python 이식이 전체적인 목적이라는 견해
    • LSP(Language Server Protocol)는 성능이 매우 중요한 코드라고 생각, IDE의 응답성에 직접적인 영향, Rust는 CPU와 메모리 모두 효율이 뛰어남, 만약 OCaml, Reason, Haskell 등으로 작성됐다면 속도나 효율은 충분히 나오겠지만 기여자 풀이 매우 한정적일 것이라는 점을 강조
    • "[툴 설명] rust"로 검색하면 성능 좋은 소프트웨어를 쉽게 찾을 수 있다는 점이 만족, 사용하는 툴 중 약 95%가 Rust로 작성되었는데 대부분 만족스럽다는 경험 공유
    • "눈에 띄게 빠르다"라는 뜻의 축약어처럼 Rust가 활용됨, 오픈 소스 Rust는 여전히 리뷰가 가능하다는 점 강조
    • Python으로 작성된 타입 체커는 성능이 부족하다는 설명, 예를 들어 Pylint와 같이 Python으로 만들어진 린터는 코드 라인마다 하나씩 체크해 30초 이상 소요되는 등, 성능이 중요한 영역이라는 주장
  • Pyre에서 Pyrefly로의 전환과 Rust로의 전면 재작성에 대한 호기심, 덜 알려진 언어에서 트렌디한 Rust로의 전환에 따른 구체적 이점 또는 동기가 궁금함
    • 이 질문은 우리의 FAQ에서 다룬다는 안내, 경험이 더 쌓이면 긴 블로그 포스트로도 이야기해보고 싶다고 전함, 링크 제공
  • 너무 많은 것을 한 번에 해결하려는 프로젝트라는 느낌이라는 의견
  • VS Code를 보고 흥미를 잃었다는 의견, 왜 사람들이 VS Code를 Python용 IDE로 적합하다고 생각하는지 이해 못 하겠다는 입장, PyCharm같은 진짜 IDE가 있는데 VS Code를 쓸 이유가 없다는 생각
    • pyrefly는 vscode에만 묶여있지 않다는 점, 다양한 사람들이 다양한 선호도를 가진다는 점을 좀 더 배려해달라는 부탁, pycharm 역시 절대적으로 더 좋지 않음, 본인은 vscode 원격 개발이 편리하고, pycharm이 별로라는 말을 인터넷에 올리고 싶진 않다는 의견
답변달기