- Rust ile yazılmış Python linter ve formatter’ı Ruff v0.16.0, varsayılan olarak etkin kuralları 59’dan 413’e çıkararak ek yapılandırma olmadan söz dizimi hatalarını ve anında ortaya çıkan çalışma zamanı hatalarını daha geniş kapsamda tespit ediyor
- Markdown’da
python, py, pyi, pycon vb. olarak işaretlenmiş Python kod bloklarını biçimlendirmeyi destekliyor ve Quarto notebook’larına da uygulanabiliyor
ruff: ignore ve ruff: file-ignore eklendi; mantıksal kod satırındaki veya tüm dosyadaki tanılamaları bastırabiliyor, --add-ignore ile yorumlar otomatik eklenebiliyorcheck ve format --check, düzeltmeleri varsayılan tanılamaların altında diff olarak gösteriyor; formatter denetimi de JSON ve GitHub/GitLab CI yorumları için çıktı biçimlerini destekliyor- Çoğu kullanıcı büyük değişiklikler yapmadan yükseltebilir; ancak artan varsayılan kuralların ve bazı değerlerin
null olabildiği JSON çıktı değişikliğinin mevcut ayarlar ve otomasyon araçları üzerindeki etkisi kontrol edilmeli
Varsayılan kurallar 413’e genişletildi
- Ruff v0.16.0, Rust ile yazılmış yüksek hızlı bir Python linter ve formatter’dır; PyPI üzerinden veya
uv tool install ruff@latest ile kurulabilir
- Ruff’ın toplam kural sayısı v0.1.0 dönemindeki 708’den 968’e çıktı, ancak varsayılan olarak etkin kurallar bugüne kadar 59’da tutulmuştu
- v0.16, varsayılan kuralları 413’e çıkararak söz dizimi hataları ve anında ortaya çıkan çalışma zamanı hataları dahil ciddi sorunları ek yapılandırma olmadan tespit ediyor
- flake8-bugbear’ın
B, pyupgrade’ın UP, Ruff’ın kendi RUF kategori kuralları vb. dahil
- Tam liste Default Rules belgesinde görülebilir
- Halihazırda
select veya extend-select kullanan projeler de yeni varsayılan kurallar sayesinde daha önce fark etmedikleri yararlı kuralları görebilir
- Önceki varsayılan kurallara dönmek için şu şekilde yapılandırılır
[lint]
select = ["E4", "E7", "E9", "F"]
- Bu değişiklik, uzun vadeli bir çalışma olan kuralların yeniden sınıflandırılması ile bağlantılıdır; ilgili çalışmalar da devam edecektir
Markdown kod bloğu biçimlendirme
ruff format, Markdown dosyalarında yer alan Python fenced code block’larını biçimlendirir- Desteklenen bilgi dizgeleri
python, py, python3, py3, pyi, pycon’dur
pyi, stub dosya biçimi olarak işlenirpycon, REPL oturumu biçimi olarak işlenir- Diğerleri normal Python dosyası gibi biçimlendirilir
- Dil adı
{python} gibi süslü parantezler içinde olsa da tanındığı için Quarto notebook’larında da kullanılabilir
.qmd uzantısı kullanılıyorsa extension eşleme ayarı gerekebilir
- Kod bloğu içinde
fmt: off ve fmt: on ile belirli biçimlendirmeler bastırılabilir
- Markdown belge alanının tamamı
<!-- fmt: off --> ve <!-- fmt: on --> HTML yorumlarıyla hariç tutulabilir
- Tüm Markdown dosyalarını hariç tutmak için
extend-exclude içine *.md gibi bir glob belirtin
- Ayrıntılı davranış Markdown kod biçimlendirme belgesinde görülebilir
Yeni tanılama bastırma yorumları
- v0.15’teki
ruff: disable·ruff: enable aralık bastırmalarının ardından v0.16, ruff: ignore ve ruff: file-ignore ekliyor
ruff: ignore, noqa gibi aynı satırdaki tanılamaları bastırabilir veya bağımsız bir yorum olarak yazılarak sonraki mantıksal satırın tamamına uygulanabilir
- Birden çok satıra yazılmış fonksiyon başlıklarında
def’ten iki noktaya kadar olan bölüm tek bir mantıksal satır kabul edilir
ruff: file-ignore, ruff: noqa gibi dosya genelinde belirtilen tanılamaları bastırır- Her bastırma yorumunda kural kodunun ardından uygulama nedeni yazılabilir
--add-ignore CLI seçeneği gerekli ruff: ignore yorumlarını otomatik olarak ekler- Önizleme modunda
F401 gibi kodlar yerine unused-import gibi kural adları da kullanılabilir
- Yorum belirtiminin tamamı Ruff linter belgesinde özetlenmiştir
Düzeltme diff’i ve çıktı biçimi
check ve format daha önce de --diff destekliyordu; ancak genel tanılamalardan ayrı çalıştığı için düzeltme nedenini gösteren tanılamalarla birlikte görüntülenmiyordu- v0.16’nın varsayılan
full çıktısı, mümkün olan linter ve formatter düzeltmelerini tanılamaların altında diff olarak gösterir
format --check de linter’ın desteklediği tüm çıktı biçimlerini kullanabilir
- Makine tarafından okunabilir JSON üretebilir
- GitHub ve GitLab’in CI’da yorum olarak işlediği biçimleri çıktılayabilir
- Desteklenen biçimler CLI yardımında ve çıktı biçimi belgesinde görülebilir
Uyumluluk ve kararlı hale getirme
- v0.16’daki kırıcı değişiklikler az sayıda olduğu için çoğu kullanıcı kodu veya ayarları büyük ölçüde değiştirmeden güncelleyebilir
- JSON çıktısındaki
filename, location, end_location, fix.edits[].location, fix.edits[].end_location, boş dize veya 1. satır 1. sütunu varsayılan değer olarak kullanmak yerine null olabilir
- Şu anda etkilenen tanılamalar çok azdır, ancak gelecekteki kurallarda bu daha yaygın hale gelebilir
- 12 kural önizlemeden kararlı duruma geçirildi
- Airflow 3 fonksiyon imzası uyumluluğu
AIR303, telif hakkı bildirimi CPY001, float dönüştürme FURB164, sıralanmış min/max FURB192
- Koleksiyon literal’larında string birleştirme
ISC004, istisna işleyici dışındaki istisna logging’i LOG004, hatalı bool dönüş tipi PLE0304
- Aşırı konumsal argüman
PLR0917, StopIteration döndürme PLR1708, Union içindeki None konumu RUF036
- Sınıf sözlüğünde annotation erişimi
RUF063, __all__ içinde yinelenen öğe RUF068
- Bazı mevcut kuralların kararlı hale getirilen davranışları da varsayılan olarak uygulanır
BLE001, istisna critical, error, exception dışındaki logging metotlarıyla kaydedilse de bastırılırFA102, collections.abc gibi ek PEP 585 uyumlu API’leri denetlerINT001·INT002·INT003, gettext’in builtins._ öğesine atanması gibi yaygın kullanım biçimlerini de denetlerS310, yanlış pozitifleri azaltmak için yerel string literal bağlamalarını çözümlerS508·S509, güncel PySNMP’nin önerilen API’sini desteklerUP019, yalnızca typing.Text’i değil typing_extensions.Text’i de tanır
- Tüm değişiklikler GitHub sürüm notlarında görülebilir
1 yorum
Hacker News yorumları
Yaklaşık 3 bin satırlık bir Python projesini v0.15.x’ten yeni sürüme yükselttim; uzun sürmedi ve önceki sürümün kaçırdığı pek çok sorunu bulup kod kalitesini de artırdı
Önerilere göre elle yapılan düzeltmeler: https://github.com/nickjj/plutus/commit/9af66d31f98bef841588...
Satır uzunluğu kuralını yeniden etkinleştirme: https://github.com/nickjj/plutus/commit/21789f89bbcee37913c1...
Kullanılmayan değişkenlere
_öneki zorunluluğu: https://github.com/nickjj/plutus/commit/a272c77b932e1c78558a...Ruff otomatik düzeltmesi: https://github.com/nickjj/plutus/commit/6fe69cf88385ebdf9b8c...
Astral’ın OpenAI tarafından satın alınmasından sonra da Ruff, ty, uv’nin aktif olarak geliştirildiğini görmek sevindirici
uv ve Ruff harika; umarım ty de bir gün o seviyeye gelir
Birbirinden keyfî kurallar uygulayan ve iyi Python kodunun ne olduğu konusunda bile uzlaşamayan sözdizimi polisi araçlarına bu kadar heyecan duyulması şaşırtıcı
Çok satırlı sözlükleri tek satıra indirip yorumların niyetini bozuyor, iki boşluk ya da çift tırnak gibi önemsiz biçimsel şeyleri düzeltiyorlar. Asıl sorun satır sonu boşluğu ya da import sıralaması değil, yorumlaması zor 10 satırlık list comprehension’lar; ama bu araçlar bunları yakalayamıyor
İş yerinde pylint, flake8, black ve Ruff kullanırken her değişiklikte yüzlerce commit oluştu; o enerjiyi başka yere harcamak daha iyi olurdu
Otomatik çalıştırma sonucunu olduğu gibi kabul ederseniz lint tartışmalarından çıkabilirsiniz; ancak bu tür araçları olmayan organizasyonlarda biçim üzerinde düşünmek ve tartışmak için gerçekten zaman harcamak zorunda kalınıyordu
Ekip geliştirmesinde kişisel tercihleri güçlü biçimde dayatmak yerine çevrenin görüşlerini dinlemek, iş birliği ile zanaatkârlığın önceliklerini yeniden gözden geçirmek gerekir
Satır yorumu varken satırları birleştirmek uygunsuz görünüyor. Çift tırnak Python’da yalnızca bir stil tercihidir; tek tırnak içinde çift tırnak varsa Ruff da onu olduğu gibi bırakır
Go’da da Ruff gibi bir araç olsa iyi olurdu. Çeşitli dillerde harika araçlar çıkıyor ama Go ekosistemi dağınık ve Ruff, Oxc, Biome, Mago kadar olgun hissettiren bir araç yok
Nispeten yeni olduğu için daha az biliniyor; ama go fix ve go vet’in temelini oluşturuyor. Go ekibi, modül yazarlarının go fix çalıştığında otomatik olarak devreye girecek özel analiz geçişlerini kolayca tanımlayabilmesi üzerinde çalışıyor gibi görünüyor
analysis.Analyzeryapısıyla AST, tip ve SSA bilgilerine erişip analizörler arasında bilgi birleştirebilirsiniz; binary olarak derleyip go fix’e verdiğinizde araç zinciri karmaşık önbelleklemeyi bile halleder. Go ekibi tarafından doğrudan yapılmış ve araç zincirine dahil edilmiş olduğundan golangci-lint gibi araçların da uzun vadede bu framework altında birleşme olasılığı yüksekBir yapay zeka ajanından Go Analysis analizörü yazmasını ve bunu go fix ile çalıştırmasını isteyebilirsiniz; ben de kendi projemde belirsiz Markdown talimatları yerine birden fazla kuralı deterministik biçimde otomatik olarak zorlamak için kullanıyorum
gofmtistiyordu. Ruff bir formatter değil, linter; yine de Python ekosisteminin son dönemdeki gelişim yönü sevindiriciResmî araçların belirli bir stili dayatmadığı Python veya TypeScript’in aksine, Go’da Ruff ya da Biome’u ilk kullandığınızda oluşan dramatik etkiyi görmek zor
Varsayılan olarak 413 kuralı etkinleştirmek, çoğu projenin ayarlara dokunmadan yararlı lint uyarıları alabilmesini sağladığı için iyi bir değişiklik
Bugünlerde bir ajana tüm lint uyarılarını belirlenen ölçütlere göre düzeltmesini verip birkaç saat bırakarak bunu çözmek mümkün olabilir, ancak Ruff’ın sunduğu ayrıntılı teşhislerin kendisi memnuniyet verici
Ruff’ta da uygulanacak varsayılanlar kümesini belirleyen Nix’in stateVersion benzeri bir özelliğe ihtiyaç var. Birden çok depoda Ruff güncellendiğinde, yeni varsayılan kurallar eklendikçe bunları hemen kapatmak ya da ihlalleri düzeltmek gerekiyor; bu da sonucu öngörmeyi zorlaştırıyor
Etkinleştirilecek tüm kuralları izin listesine yazmak da mümkün, ancak yapılandırmayı basit tutup herkes birkaç saat ayırabildiğinde yalnızca durum sürümünü yükseltmek daha iyi
pyproject.tomliçinde istenen Ruff sürümünü sabitlemek daha uygun bir yaklaşım. Her proje hazır olduğunda sürümünü yükseltebilir; böylece birden çok projeyi aynı anda koordine etmek gerekmez ve biri geride kalsa bile diğerleri takılmazhttps://github.com/astral-sh/ruff/releases/tag/v0.1.0
Ajanla kodlama çağında güçlü linting her zamankinden daha önemli; daha fazla dilde forbidigo benzeri araçlar görmek isterim
Kodlama ajanları da küçük sorunları düzeltmek için çok fazla token harcayabiliyor ya da testler başarısız olursa bunları tamamen devre dışı bırakabiliyor. Yapay zeka çıktılarının genel doğruluğuna güvenmeye başladım, ama kod kalitesi konusundaki muhakemesine hâlâ güvenmek zor
Kurallar 413 tane olmasına rağmen, yeni bir kod tabanına her katıldığımda import sıralamasıyla ilgili aynı üç tartışmayı tekrar yaşıyorum
Artık yapılandırmasız kullanımın öneriliyor gibi görünmesi sevindirici. Yeni
.ruff.tomldosyasında yalnızcaline-length = 300olması yeterli