Hacker News 의견들

• 이 비교표에 Ty가 추가되면 좋겠음
  Python typing conformance 결과표를 보면 Pyright의 성능을 과소평가하면 안 된다고 생각함
  Emacs에서 Ty(LSP)를 잠깐 써봤는데 꽤 잘 작동함. 다만 메서드 시그니처가 표시될 때 일부 파라미터의 타입 주석이 너무 장황하게 보이는 점이 조금 거슬림
  그래도 장기적으로 Ty를 쓸 가능성이 높다고 봄. 첫 베타 출시 축하함

  • 사양 준수도 중요하지만, 그걸로 타입 체커를 선택하는 건 추천하지 않음
    실제 사용자들이 중요하게 여기는 부분과는 거리가 있음. (나는 Python Typing Council에서 스펙과 테스트를 함께 만들었음)
  • 우리도 곧 그 표에 추가할 예정임. Pyright 수준의 conformance를 따라잡으려면 시간이 좀 걸리겠지만, 정식 출시 전까지 그게 목표임
  • Pyright도 훌륭하지만 BasedPyright이 그 위에 더 개선된 버전임
    그래도 나는 uv의 만족스러운 사용자라 Ty가 충분히 안정되면 옮길 생각임
  • 이 PR은 아직 WIP 상태지만, 다시 OSS 기여를 시작할 동기부여가 됐음
  • Pyright는 좋지만 속도가 느림. LSP의 반응 속도는 UX에 큰 영향을 주기 때문에 Ty가 얼마나 개선했을지 기대됨

• Astral이 훌륭한 도구를 만들고 있으니, 파괴적인 수익화 없이 잘 성장하길 바람

  • Astral의 첫 상용 제품은 pyx임. 성공해서 계속 멋진 오픈소스 도구를 만들어가길 바람
  • 지금까지의 작업은 Python 커뮤니티에 대한 공공 서비스 수준이라고 생각함
  • 방향성은 bun과 비슷하게 가는 느낌임
  • 다만 기존 도구를 완전히 대체한다고 주장하면서 실제로는 기능을 다 구현하지 않는 점이 아쉬움
    결국 기존 도구로 되돌아가야 하는 경우가 생김. 나에게는 속도보다 정확한 타입 검사가 더 중요함

• Astral 팀에게 감사함. 우리는 Pydantic을 많이 쓰고 있어서 Ty의 정식 릴리스에서 1급 지원이 예정되어 있다니 기대됨
  현재는 Pyright와 Mypy를 함께 돌리고 있는데, 서로 다른 오류를 잡아내서 중복된 느낌임
  이 표에 따르면 Pyright가 superset이라는데, 실제 경험은 달랐음
  2년 전 분석이라 지금은 다를 수도 있음. 대규모 코드베이스에서 Pyright 하나로 통합한 사례가 있는지 궁금함

  • 나도 mypy 초기 사용자로서 Pyright가 VS Code에 추가되었을 때 비교해봤음
    mypy가 더 유연하고 정확하게 추론하는 경우가 많았고, Pyright는 false positive가 많아서 꺼둔 적도 있음
    요즘은 Pyright가 많이 발전했겠지만, BasedPyright는 오히려 비생산적이었음
    커뮤니티에서 mypy를 깎아내리고 Pyright를 찬양하는 분위기가 강한데, 내 경험과는 좀 다름
  • 다시 말하지만, 스펙 준수 테스트는 실제 사용자 경험을 반영하지 않음
    주로 주석의 의미론에 집중하기 때문에 타입 체커 선택 기준으로 삼기엔 부적절함
    (나도 Python Typing Council에서 이 스펙과 테스트를 만들었음)

• 제목은 “Ty 베타 릴리스 발표”가 더 적절했을 것 같음
  나는 Pyrefly를 Pyright보다 선호했는데, 최근 버그로 이전 버전에 고정해야 해서 불편했음
  Ty를 설치하려 했더니 Cursor 버전 호환 오류가 발생했음

  • 혹시 추가 오류 메시지가 있다면 이슈 등록 부탁함. 나는 Cursor에서 Ty 확장을 몇 주째 잘 쓰고 있어서 재현이 어려움
  • (Pyrefly 메인테이너임) 그 크래시도 Pyrefly 저장소에 이슈로 남겨주면 좋겠음

• 아직도 한 언어에 이렇게 많은 타입 체커가 존재하는 이유를 모르겠음
  라이브러리 제작자는 모든 체커에 대해 테스트해야 하나? 개발자는 특정 체커를 지원하는 라이브러리만 써야 하나?

  • Python은 덕 타이핑 + 선택적 타입 주석 언어라서 다양한 구현이 생길 수밖에 없음
  • 일부는 호출자 추론 범위나 명시적 타입 요구 정책이 달라서 생긴 차이임
    패키지 경계에서는 명시적 타입이 필요하지만, 내부 코드에서는 모호함이 많음
    Astral은 특히 증분 처리 성능을 주요 설계 목표로 삼고 있음
  • 실제로는 대부분 mypy 기준으로 테스트함. Pyright는 VS Code 기본 확장 덕분에 점점 영향력을 넓히는 중임
    필요하면 직접 type stub을 제공해서 호환성을 확보할 수도 있음

• Ty가 “타입 체커를 만족시키기 위해 주석을 추가할 필요가 없다”는 입장을 취한 게 마음에 듦
  이전 체커는 사소한 경고로 귀찮게 했지만, Ty는 실제 논리적 오류를 잘 잡아줌

• Ty가 언어 서버(LSP) 역할도 한다는 걸 오늘 처음 알았음
  즉, Neovim이나 VSCode에서 mypy와 Pyright를 모두 대체할 수 있음

• Django 지원은 어떤지 궁금함. Django는 매직 코드가 많아서 타입 체커가 다루기 어려움

  • Ty는 아직 Django를 지원하지 않으며 플러그인 시스템도 없음
    Django를 쓴다면 당분간은 mypy나 Pyright를 유지하는 게 좋음

• Ty가 빠르지 않더라도 교차 타입(A & B) 지원만으로도 쓸 만하다고 생각함
  표준 Python 타입 시스템에서 빠져 있는 기능이라 반가움

• Ruby에도 uv 같은 게 있는지 궁금함. Python이나 TypeScript에서는 uv나 bun을 쓰는데, Ruby는 뒤처진 느낌임

  • Rv라는 새로운 Ruby 관리 도구가 있음. 이게 그 대안이 될 수도 있음