Python’ın Rust tabanlı iki yeni type checker’ı Pyrefly ve Ty karşılaştırması

• Son dönemde Meta’nın Pyrefly’ı ve Astral’ın Ty’si olmak üzere Rust tabanlı iki Python type checker’ının duyurulması, mevcut mypy ve pyright’a kıyasla ezici bir performans ve yeni bir typing paradigması sunduğunu gösterdi
• Pyrefly agresif type inference ve open source yaklaşımını benimserken, Ty ise “gradual guarantee” ilkesini getirerek type error oluşumunu en aza indirmeye odaklanıyor
• Her iki araç da erken alfa sürümünde olsa da, çeşitli projelerde yapılan benchmark sonuçlarında Ty ortalama olarak daha hızlı çalışma süresi kaydediyor
• Artımlı analizde Pyrefly modül düzeyinde, Ty ise fonksiyon hedefi düzeyinde daha ince taneli bir artımlılık sunuyor; bu da kullanılabilirlik ve yapı açısından farklılık yaratıyor
• Ty, intersection type ve negation type gibi yenilikçi type system özellikleri sunuyor ve daha sezgisel, daha net hata mesajları sağlıyor

---

Pyrefly ve Ty’ye giriş

• Pyrefly ve Ty, Rust ile geliştirilmiş Python type checker’lardır
• Pyrefly, Meta (eski adıyla Facebook) tarafından geliştirildi ve mevcut OCaml tabanlı Pyre’ın yerini alıyor
• Ty, Astral tarafından geliştirildi; Astral ise uv, ruff gibi Python araçlarıyla tanınıyor
• Her iki proje de open source olarak yayımlanıyor, ancak henüz resmî sürüm öncesi alfa aşamasında
• Her iki ekip de PyCon 2025 Typing Summit’te kendi vizyonlarını, hedeflerini ve yaklaşımlarını tanıttı

Ortak noktalar

• İkisi de Rust ile geliştiriliyor ve artımlı analiz (Incremental Checking) destekliyor
• Python kodunun AST parsing işlemi için ruff kullanılıyor
• Komut satırı type checking’i ve LSP/IDE entegrasyonu desteğiyle geliştirme ortamına bağlanma konusunda da güçlüler

Fark 1: Hız

PyTorch benchmark’ı

• Ty, Pyrefly’dan yaklaşık 2~3 kat daha hızlı; her ikisi de mevcut mypy ve pyright’tan 10~20 kat daha hızlı
• Pyrefly, Pyre’a kıyasla 35 kat, mypy/pyright’a kıyasla 14 kat performans artışını hedefliyor
• Ty, mevcut nesil type checker’lardan bir veya iki basamak daha hızlı olacak şekilde tasarlanmış durumda

Django benchmark’ı

• En hızlı sonuç Ty’de, onu Pyrefly izliyor
• Pyright belirgin biçimde daha yavaş sonuç veriyor

mypy deposu benchmark’ı

• Benzer sonuçlarda yine Ty en hızlı, Pyrefly ise küçük bir farkla arkasından geliyor
• mypy ve pyright belirgin derecede daha yavaş çalışma süreleri kaydediyor

Fark 2: Typing hedefleri

Pyrefly

• Kodda ayrıca açık type tanımları olmasa bile olabildiğince type inference yaparak hataları yakalamayı hedefleyen bir strateji izliyor
• Daha agresif type çıkarımı ile kod kararlılığını en üst düzeye çıkarmayı amaçlıyor

Ty

• Gradual guarantee (kademeli güvence) ilkesini uyguluyor
• Çalışan bir kodda açık type’lar kaldırıldığında type error oluşmaması hedefleniyor
• Type annotation olmasa da hata üretmiyor; yalnızca gerektiğinde ek annotation istiyor
• Örneğin açık type’ı olmayan bir alana değer atansa bile type error üretmiyor, bunu Unknown | None gibi bir biçimde ele alıyor

Fark 3: Artımlı analiz yöntemi

• Pyrefly: Değişen dosyayı (modülü) ve ona bağımlı modülleri yeniden analiz ediyor (modül düzeyinde artımlılık)
• Ty: Rust’ın Salsa framework’ünü kullanarak fonksiyon düzeyine kadar ince taneli artımlılık sağlıyor
• Modül düzeyi yaklaşımın yeterince hızlı olduğu düşünülürken, fonksiyon düzeyi yaklaşım kod tabanını daha karmaşık hâle getirebilir; burada araçların stratejileri ayrışıyor

Fark 4: Özellikler (type system ve destek)

Pyrefly’ın güçlü yanları

• Örtük type inference oldukça güçlü
• Açık type tanımı olmadan da fonksiyon dönüş değerleri, sözlükler, listeler gibi karmaşık type’ları analiz edip hataları yakalayabiliyor
• Generic ve overload ile wildcard import gibi karmaşık typing sorunlarına odaklanacak şekilde tasarlanmış
• Generic type inference doğruluğu, Ty’ye kıyasla daha yüksek

Ty’nin ayırt edici yönleri

• “gradual guarantee” sayesinde açık type tanımı olmadığında type değişimlerine daha serbest izin veriyor
• Intersection type ve negation type gibi yenilikçi type system desteği sunuyor
• Hata mesajları çok açık ve sezgisel olacak şekilde tasarlanmış
• Liste gibi yapılarda farklı type’ların atanmasına esnek biçimde izin veriyor ve sistem düzeyinde Unknown type değerini kullanıma sokuyor

Sınırlamalar / alfa durumu

• Her iki ürün de alfa aşamasında; type inference veya bazı özellikler henüz tamamlanmış değil
• Örneğin Ty’nin liste type inference’ı gibi bazı sonuçlar hâlâ yeterince olgun değil

Ayrıntılı özellik karşılaştırması

Örtük type inference

• Pyrefly, dönüş type’larını ve koleksiyon nesnelerinin type’larını etkin biçimde çıkarıyor; revealed type ve hataları da net biçimde gösteriyor
• Ty, inference yetersiz kaldığında Unknown veya @Todo döndürüyor

Generic’ler

• Hem Pyrefly hem de Ty, genel generic type problemlerini iyi çözüyor
• Pyrefly, type parametresi olmadan oluşturulan instance’ların yorumlanmasında üstünlük sağlıyor
• Her iki checker da covariance/contravariance sorunlarında mypy ve pyright’a kıyasla daha zayıf kalıyor

Hata mesajları

• Ty, kısa ve okunması kolay error message’lara odaklanıyor
• Pyrefly, mypy ve pyright’a kıyasla tek bakışta anlaşılması daha kolay mesajlar sunuyor

Intersection / negation type’lar

• Yalnızca Ty, intersection type (&) ve negation type (~) destekleyerek aşağıdaki gibi karmaşık type işlemlerini gerçekleştirebiliyor

  • Örnek: WithX | Other type’ında x özelliği varsa, Ty bunu otomatik olarak WithX olarak dallandırıyor
  • Örnek: Belirli bir subclass değilse, type’ı MyClass & ~MySubclass olarak yorumluyor

• Bu tür intersection ve negation type’ları, type theory açısından oldukça ileri özellikler

Diğer ileri örnekler

• Ty, type system sayesinde Diofant denklemleri gibi karmaşık işlemlerde de kullanılabiliyor
• Testler Markdown belgeleri olarak yazılıyor (bkz: Astral ruff’un mdtest kaynakları)

Sonuç ve beklentiler

• Python ekosistemine ezici derecede hızlı ve yeni bir type checker sınıfı girmiş durumda
• Ty, kademeli type güvenliğini; Pyrefly ise aktif type inference’ı ana strateji olarak benimsiyor
• Her iki araç da çok erken aşamada olduğundan, ileride özelliklerinin yakınsaması veya evrilmesi için geniş bir alan var
• Resmî sitelerinden denenebiliyor; ayrıca VSCode, Cursor gibi başlıca editörler için eklentileri de sunuluyor
• İleriye dönük olarak Google’ın da Go tabanlı bir type checker’ı open source yapacağına dair söylentiler var; bu da Python type analysis alanını daha da zenginleştirebilir

Kullanım / referans

• Pyrefly: pyrefly.org/sandbox
• Ty: play.ty.dev
• Astral’ın Ty aracı Markdown tabanlı testler kullanıyor (ayrıntılı yol için ruff reposundaki mdtest’e bakılabilir)
• Resmî belgeler, editör eklentileri ve paket kurulum komutları da sağlanıyor

[q8840]

Görünüşe göre ty, kullanılan fonksiyonda dönüş türü yazılmamışsa bunu koşulsuz olarak unknown kabul ediyor; ancak kaydedince kontrol ediyor.
pyrefly ise yazılmamış olsa bile çıkarım yapıyor ve yazarken de kontrol ediyor.

[GN⁺]

Hacker News görüşü

• ty geliştiricisi olarak, ty ve pyrefly'ın giderek daha fazla ilgi görmesinden memnun olduğunu vurguluyor; ancak her iki projenin de henüz tamamlanmış olmadığını bir kez daha hatırlatıyor. Eksik özelliklerden kaynaklanan örnekler gördüklerini, bir şey “bu garip” diye düşündürdüğünde bunun aslında henüz geliştirilmemiş bir kısım olabileceğini anlayışla karşılamalarını rica ediyor. Python'ın son derece büyük ve çeşitli bir dil olduğunu kabul etmek gerektiğini belirtiyor.

  • ty'nin Markdown tarzı test yaklaşımını gerçekten çok beğendiğini söyleyen bir görüş var; testlerin aynı zamanda belge işlevi görmesi son derece iyi bir fikir. Bu yaklaşımın fikrinin Rust'ın dokümante edilmiş kod örneklerinden esinlenip esinlenmediğini merak ediyor.

  • Tipi ortaya koyan kısımların @TODO ile işaretlenmiş olmasının güldürdüğünü, ama düşününce bunun epey zekice ve kullanışlı bir düzenek olduğunu söyleyen bir izlenim var.

  • TypeScript deneyimi olan biri olarak, tip çıkarımı, tip daraltma ve her Python tip denetleyicisinin farklı davranması gibi çeşitli denemeleri ilginç buluyor. Hâlâ hızlı ve güvenilir bir tip denetleyicisine kesinlikle ihtiyaç olduğunu, ama Python'ın bu konuda oldukça geride kaldığını düşünüyor. Tip denetleyicilerinin kod üretkenliğini ve güvenilirliğini artırması gerektiğine inanıyor ve bu tür projeleri destekliyor.

  • Bir Rust geliştiricisinin bakış açısından “Rust için betik dili” hakkında soru var: Rust ile sözdizimsel olarak iyi uyum sağlayan, Rust tiplerini yerel olarak içe aktarabilen ve hızlı derleme/hot reload yapabilen bir dil üzerine çalışan bir ağ olup olmadığını merak ediyor. Sözdizimi farklı olsa bile Python'ın bu rolü üstlenme ihtimali hakkında da görüş istiyor. İlgili bağlantı eklenmiş: https://news.ycombinator.com/item?id=44050222

• Python deneyimi çok olmayan dışarıdan bir bakışın görüşü: tip ipuçlarının kullanımıyla ilgileniliyorsa şu Reddit yazısına bakılması öneriliyor: https://www.reddit.com/r/Python/comments/10zdidm/why_type_hinting_sucks/. Ancak bu yazının fazla ciddiye alınmaması gerektiği, ne kadar iyi tip araçları olursa olsun önce “iyi pratiklerin” gelmesi gerektiği vurgulanıyor. Örnek olarak, Django veya Meta gibi büyük kod tabanlarında tutarlı kullanım ve sıkı tip denetimi için geliştiricilerin önerilen teamüllere uymasının sağlanması gerektiği söyleniyor. Python'ın, C++ gibi fazla çok özellik ve hoşgörülü bir çalışma zamanına sahip olduğu için sonuçta yalnızca bir kısmının sınırlı biçimde kullanılmasının yönetimi kolaylaştırdığı, ancak bu sınırlı kısmın insanlara ve amaçlara göre değişebileceği belirtiliyor. Rust geliştiricilerinin daha katı tip sistemleri yüzünden Linux çekirdeği geliştiricileriyle yaşadığı sürtüşmelere de benzetiliyor.

  • İlgili Reddit yazısındaki üst yorumlardan birinin, “Any kullanılır, dolayısıyla tartışma anlamsız” şeklinde konuyu geçiştirdiği söyleniyor. Oysa gerçek örneklerde daha açık tip bildirimleri olsaydı, kütüphane fonksiyonlarındaki gelecekteki değişiklikler ya da beklenmedik girdiler nedeniyle oluşabilecek hataların önceden engellenebileceği belirtiliyor. Python kodunun sürdürülebilir ve güvenilir olması için tip denetiminin zorunlu olduğu yönünde güçlü bir görüş dile getiriliyor.

  • Python tip denetimine fazla zaman ve emek harcamaktansa, doğrudan daha uygun bir statik tipli dile geçip yalnızca gerekli yerlerde Python'ı birlikte çalışabilirlik katmanı olarak kullanmanın daha iyi olduğu sonucuna varılıyor. Bunun her zaman mümkün olmadığı kabul edilse de, Python'ı zorla uydurmaya çalışmanın büyük zaman kaybı olduğu düşünülüyor.

  • Python'ın güçlü ve karmaşık özellikleri (ör. meta class, descriptor, __call__ kullanımı, object.__new__, ad mangling, self.__dict__) çok fazla sihir içerdiği ve kod okunabilirliğini ciddi biçimde düşürdüğü gerekçesiyle eleştiriliyor. Kişisel olarak bu özellikleri kullanmayacağını söylüyor.

  • Gerçekte o dili kullanmadan fikir belirtmenin nereden kaynaklandığını merak eden bir yorum var. Python geliştiricileri dili gerçekten kullanarak derinlemesine anlarken, kullanmayan birinin dışsal gerekçelerle dili eleştirmesi ilginç bulunuyor. contrived example'lar (zorlanmış örnekler) üzerinden tartışma yürütülmesi eleştiriliyor.

  • Uzun yıllardır Python kullanan biri olarak, en büyük hatanın tip ipuçlarını ve tip denetleyicilerini hiç kullanmamak olduğunu kesin bir dille söylüyor.

• ty'nin “kademeli garanti”si (gradual guarantee) ilgi çekici bulunuyor; yani tek bir tip anotasyonunu kaldırmanın bile tip hatasına yol açmaması gerektiği fikri cazip geliyor. Dinamik kodun çok olduğu Python için en uygun yaklaşımın bu olduğu düşünülüyor.

  • Kademeli tiplerin, kodun herhangi bir yerinde any (belirsiz tip) bulunsa bile uyarı vermeyen bir yapı sunduğu; bunun da önemli kodlarda bile tam tip güvenliğini sağlayamayarak yeterli koruma vermediği hatırlatılıyor. mypy kullanım deneyiminde de bunun ölümcül bir eksiklik olduğu, “bu dosya tamamen statik olarak tip denetlenir” şeklinde bir bildirim özelliğinin kesinlikle gerekli olduğu söyleniyor. Kişisel görüş olarak “kademeli” tiplerin neredeyse bir anti-pattern olduğu, hatta “soft typing” teriminin daha uygun olabileceği ifade ediliyor.

  • Mevcut kod tabanlarında kademeli tiplerden başka yol olmadığı görüşü de var. mypy ile birçok eski Python kod tabanına tip ipuçları ekleme deneyimine göre, “modül bazında opt-in” en makul yaklaşım. pyrefly bunu desteklemiyorsa pratik kullanımının sınırlı olacağı düşünülüyor. Bununla birlikte, llm (büyük dil modeli) kod üretimi açısından bakıldığında çok hızlı ve katı bir tip denetleyicisinin faydalı olabileceği belirtiliyor.

  • Bunun TypeScript'in ilk dönem benimsenmesine benzediği söyleniyor. Mevcut büyük projelerde yumuşak bir onboarding önemseniyor; zamanla noImplicitAny veya strict seçenekleri modül bazında açılarak sonunda güçlü tip doğrulama ortamına geçilebiliyor.

  • Bir Rust programcısı olarak da “kademeli garanti”nin en mantıklı yaklaşım olduğunu düşündüğünü söylüyor.

  • Kademeli tip desteği yaklaşımını kişisel olarak çok çekici bulmadığını belirten bir görüş var. Zaten Python'ın dinamik tip sistemi güven vermediği için, tip anotasyonu eklemenin amaçlarından yarısının bu hatalı davranışları kontrol altına almak olduğu söyleniyor. Bu yüzden no-implicit-any ya da strict mod seçeneklerinin mutlaka gerekli olduğu isteniyor.

• Astral'ın araçları Python ekosistemine taze enerji getiriyor, ancak “uzun vadeli bakış” konusunda soru işaretleri var. Gelecekte doğrudan Python'a entegre mi olacak? 5 yıl içinde ortadan mı kaybolacak? Abonelik temelli bir rug pull mı yaşanacak?

  • Business Source License yoluyla, Astral araçlarını kullanan üretim dağıtımlarında kurumsal abonelikleri zorunlu kılmaya yönelme ihtimalinin yüksek olduğu söyleniyor. Mevcut ürünlerin tam olarak bu amaca yönelik olmadığı kabul edilse de, risk sermayesi yatırım mantığı açısından benzer bir modele gidilebileceği düşünülüyor.

  • Resmî duyuruda Astral'ın araçların üzerine çeşitli hizmetler satacağını açıkça belirttiği söyleniyor. Referans bağlantı: https://astral.sh/blog/announcing-astral-the-company-behind-ruff

  • Aslında bu kaygının yalnızca Astral'a özgü olmadığı, tüm projeler için geçerli olduğu; özellikle Facebook araçlarının zamanla bakım dışı kalma riskinin yüksek olduğu uyarısı yapılıyor. Sonuçta kullanıcıların her zaman riski kendilerinin üstlenmesi gerektiği tavsiye ediliyor.

  • Reddit'teki bir kullanıcının görüşü aktarılıyor: VC modelinin özü, sonunda FAANG benzeri büyük teknoloji şirketlerine satılmayı ummak ya da yeterince büyüyüp tehditkâr hâle gelerek bir acqui-hire hedefi olmak. Astral için de satın alma-birleşme sonrası yetenek transferi gibi senaryoların mümkün olduğu söyleniyor.

  • Son zamanlarda Astral'ın büyük şirketlere yönelik araçlar, örneğin barındırılan özel paket registry'leri gibi çözümler de hazırladığına dair söylentiler olduğu belirtiliyor.

• “my_list = [1, 2, 3]” örneğinde mypy, pyrefly ve pyright my_list.append("foo") çağrısını tip hatası sayarken, yalnızca ty'nin bunu ayrıca açıkça belirtilmeden kabul etmesi eleştiriliyor. Gerçek işlerde tek tipli listelerin standart olduğu, bu yüzden tip denetleyicilerinin bunu varsayması gerektiği savunuluyor. Python izin veriyor diye tip doğrulamanın gevşekleşmemesi gerektiği güçlü biçimde söyleniyor; bunun acemi koduna göre optimize edilmiş bir politika olup olmadığı soruluyor.

  • ty geliştiricisi olarak, “liste literal tip çıkarımı henüz tamamlanmadı” açıklaması yapılıyor. Şu anda yalnızca list[Unknown] kullanıldığı ve Unknown'ın Any'e benzer kademeli bir tip olduğu için append işlemlerinin hepsine izin verildiği anlatılıyor. İleride daha hassas çıkarım planlandığı ve ilgili tartışma için şu issue'nun paylaşıldığı belirtiliyor: https://github.com/astral-sh/ty/issues/168

  • Bunun acemilere göre optimizasyon değil, eski kodlarla uyumluluk için kaçınılmaz olduğu görüşü de var. Büyük, tipsiz kod tabanlarına tip denetleyicisi getirilecekse mevcut kodun olabildiğince olduğu gibi çalışması gerektiği, aksi hâlde yükün artacağı anlatılıyor.

  • “Python'ın izin verdiği şeyi yok sayıp kişisel kanaatle tooling üretmek ikna edici değil” şeklinde bir karşı görüş de var.

  • pyrefly yaklaşımının sorunu olarak, “büyük ve tipsiz kod tabanlarında tam ölçekli benimsemenin zor olması” gösteriliyor. Kodun tek tek düzeltilmesi gerektiğinden, kurum içinde bu işe yönelik bir uzlaşma yoksa bunun kolay olmayacağı söyleniyor. Meta gibi bunu içeride dayatabilen yerlerde sorun olmayabilir, ancak kademeli geçiş düşünüldüğünde ty gibi daha hoşgörülü bir yaklaşımın daha gerçekçi olduğu belirtiliyor. Yine de kişisel olarak mixed tipler için uyarı veren araçların tercih edildiği söyleniyor.

  • “Çalıştırılabilir Python koduysa, açıkça tip kısıtı konmadıkça tip hatası vermemesi doğrudur” görüşü de dile getiriliyor. Daha katı bir statik alt küme isteniyorsa tip anotasyonlarının doğrudan eklenebileceği söyleniyor.

• Pyrefly yaklaşımının tip çıkarımını daha güçlü biçimde hedeflediği, bu yüzden gerçekten tip güvenli büyük kodlarda gereken anotasyon miktarını çok azalttığı; ilk benimseme zor olsa da uzun vadede daha verimli olduğu yönünde deneyimli bir görüş var. ty'nin ise fiilen noImplicitAny seçeneği kapatılmış gibi davrandığı söyleniyor.

• Ciddi notebook (live coding) entegrasyonu olan bir tip denetleyicisine dair beklenti dile getiriliyor; statik denetimle uzun hücreleri çalıştırmadan önce hataların yakalanmasının çok büyük verim sağlayacağı düşünülüyor.

  • VSCode'da Jupyter notebook kullanma deneyimi soruluyor; pylance gibi tip denetleyicilerinin deneysel kod için bazen engelleyici olabildiği belirtiliyor.

  • Notebook entegrasyonu ve live coding sırasında anında geri bildirim sağlayan VSCode Language Server deneyimi öneriliyor; bunun notebook entegrasyonu ve canlı etkileşimli tip denetimi ihtiyacını karşıladığı anlatılıyor.

• Pyrefly'ın tasarımının TypeScript'in tip çıkarımı yaklaşımına benzediği için kişisel olarak daha mantıklı bulunduğu, modül bazında kademeli (incemental) benimsemenin ideal sayıldığı belirtiliyor. İşlev düzeyine kadar inmenin fazla ayrıntılı olacağı ve gereğinden fazla kaçacağı düşünülüyor. Performans açısından da modül düzeyinin yeterli olduğu değerlendiriliyor.

• Projede dinamiklik fazla olsa bile Pyrefly gibi daha güçlü tip çıkarımının tercih edildiği, bunun getireceği rahatsızlıklara rağmen yine de o tarafta olunacağı söyleniyor.

• Şu anda IDE ve CI ortamında basedpyright kullanıldığı, genel olarak kararlılığından memnun kalındığı; mypy'nin ise basit tip işleri konusunda bile zaman zaman başarısız olduğu için pek sevilmediği belirtiliyor.