Python'un “PEP-302 Yeni İthalat Kancaları” Deneyimi [kapalı]


40

Ben Ruby (CRuby) 'nin geliştiricilerinden biriyim. Ruby 2.0 sürümü üzerinde çalışıyoruz (2012 / Şubat'ta piyasaya sürülmesi planlanıyor).

Python'un "PEP302: Yeni İthalat Kancaları" (2003):

Bu PEP, Python içe aktarma mekanizmasının daha iyi özelleştirilmesini sağlayan yeni bir ithalat kanca seti eklemeyi teklif ediyor. Mevcut ithal kancanın aksine , mevcut şemaya yeni bir stil kanca enjekte edilebilir ve bu da modüllerin nasıl bulunduğunun ve nasıl yüklendiğinin daha iyi bir şekilde kontrol edilmesini sağlar.

PEP302'ye benzer bir özelliği Ruby 2.0'a (CRuby 2.0) dahil etmeyi düşünüyoruz. Matz'ı ikna edebilecek bir öneride bulunmak istiyorum. Şu anda, CRuby komut dosyalarını yalnızca dosya sistemlerinden standart bir şekilde yükleyebilir.

PEP 302 ile ilgili deneyiminiz veya düşünceniz varsa, lütfen paylaşın.

Örnek:

  1. Harika bir özellik. Değiştirmene gerek yok.
  2. Neredeyse iyi, ama bu sorun var ...
  3. Eğer 2003'e geri dönebilseydim, o zaman ...

6
Vay, YARV adam kendisi, merhaba ve Programcılar hoş geldiniz! ;) Stack Exchange'de açık uçlu tartışmayı gerçekten sevmiyoruz, bunun yerine belirli problemleri çözmeyi seviyoruz ( SSS bölümümüzü hızlıca okuyun ) - sanırım sorunuzun Stack Overflow'ta kapatıldığını ve bunun zaten buradaki yakın oy. Bunu biraz daha spesifik kılmaya çalışmalısınız - bu soruyu motive eden PEP 302 hakkında özel bir endişeniz var mı?
yannis

4
Yorumunuz için teşekkürler, Yannis. Sanırım "yazılım mimarisi" hakkında tartışmak istiyorum. PEP302, kendi yükleyicilerini python yorumlayıcısına genişletmek için güçlü ve genel bir çerçeve gibi görünmektedir. Bununla birlikte, güçlü özellik, tercümanın optimizasyonunu engelleyen aşırı kullanım (büyülü kodlar üretir) gibi risklere sahiptir. Bu yüzden bu eklenti çerçevesinin piton kullanıcıları ve tercüman geliştiricileri için tatlı olup olmadığını bilmek istiyorum . Tarih okumanın Ruby 2.0'da iyi bir açıklama yapmama yardımcı olacağını düşünüyorum.
Koichi Sasada

Sorumu güzel değiştirdiğiniz için teşekkür ederim. Üzgünüm, eğer bu soru tercih edilemezse.
Koichi Sasada

Bu, yüzeyde "görüş yoklama" testimizde başarısızlığa uğramış gibi görünen bir sorunun yine de şaşırtıcı bir değere sahip olabileceğini gösteren harika bir örnek.
Ross Patterson

Yanıtlar:


47

Python'un runpy modülünün sahibiyim ve mevcut ithalat sisteminin bakımcılarından biriyim. İthalat sistemimiz etkileyici bir şekilde esnek olmasına rağmen, birkaç değişiklik yapmadan toptan satışa geçmesini tavsiye ediyorum - geriye dönük uyumluluk endişeleri nedeniyle, olması gerekenden daha garip olan birçok şey var.

Python'da PEP 302 ile acı veren şeylerden biri, çekirdek ithalat sistemini kullanmaya dönüştürmemizin ne kadar sürdüğü. On yılın daha iyi bir kısmı için, ithal kancalarla karmaşık bir şey yapan herkes iki parçaya takılıp kaldı: bir tanesi PEP 302 uyumlu yükleyicileri kullanıyor (zip ithalatı gibi) ve ikincisi standart dosya sistemi tabanlı ithalat mekanizmasını kullanıyor. Önümüzdeki 3.3'te, PEP 302 yükleyicilerin taşınması, standart dosya sistemi içe aktarma mekanizmasından içe aktarılan modüllerle de ilgilenecektir. Eğer kaçınabiliyorsanız, bu hatayı tekrar etmemeye çalışın.

PEP 420 (Python 3.3 için uygulanmıştır), ithalatçıların isim alanı paketlerine bölümlerini katkıda bulunmalarını sağlamak için protokole bazı eklemeler yapar. Ayrıca, Finder API tanımındaki bir adlandırma sorununu da düzeltir (yanlış kullanılan "find_module" ifadesini daha doğru "find_loader" ile değiştirerek). Bunun umarım hepsi, 3.3rc1 birkaç hafta içinde yuvarlanıncaya kadar dilin belirttiği şekilde daha net belgelenmelidir.

Dikkat çeken bir diğer sorun, özellikle PEP 302'de belgelenen yaklaşımın çok fazla küresel süreç süreci olmasıdır. Bizi bu yoldan takip etmeyin - durumu daha tutarlı bir nesne modelinde kapsüllemeye çalışın, böylece diğer modülleri seçmeli olarak içe aktarmak biraz daha kolaydır (C uzatma modülleri, bu tür bir kapsüllemeyi tamamen etkili kılma, hatta bir miktar kapsülleme seviyesine sahiptir. yardımcı olabilir).

PEP 406 (http://www.python.org/dev/peps/pep-0406/) Python'un gelişmiş durum kapsülleme yaklaşımının geriye dönük uyumlu bir evrimini tartışıyor. En başından kapsüllenmiş bir durum modeliniz varsa, API'lerinizi buna göre tanımlayabilir ve ithalatçıların ve yükleyicilerin genel duruma erişmelerini önleyebilirsiniz (bunun yerine aktif motora bir referanstan geçmek).

PEP 302'deki bir başka eksik parça, ithalatçı tarafından sağlanan modüller üzerinden bir yineleyici için ithalatçı talep etme kabiliyetidir (donma programları ve dokümanlar çıkaran otomatik dokümantasyon araçları gibi şeyler için gereklidir). : İnanılmaz derecede kullanışlı olduğu için, muhtemelen olsun halindeyken onu standartlaştırılması daha iyi olurdu http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules muhtemelen nihayet resmen belirtilen bu yükseltmek edeceğiz ( Python'daki API 3.4)

Ve son yorumum, ithalat sistemi ile yükleyici nesneleri arasındaki sorumluluk dağılımına yakından bakmanız gerektiğidir. Özellikle, "load_module" API'sini "init_module" ve "exec_module" adımlarına ayırmayı düşünün. Bu, yükleyicilerin doğrudan ithalat durumu ile etkileşime girmesi gereken dereceyi en aza indirmenizi sağlar.

PEP 302 ve importlib daha esnek bir ithalat sistemi için harika bir başlangıç ​​noktasıdır, ancak kesinlikle kaçınılması gereken hatalar var.


1
Onlar değil oldukça henüz bitmiş, ama tam alma sistemi docs bir başlangıç taslağı bulunabilir docs.python.org/dev/reference/import
ncoghlan

1
python.org/dev/peps/pep-0451 , Python’un Python 3.4 için yaptığı açıklamada, Brett ve ben burada bulunan yorumların birçoğunu ele alan bir güncellemedir.
ncoghlan

28

Ncoghlan'ın yanında, Python'un ithalat sisteminin diğer sağlayıcısı ve mevcut uygulamasının yazarı olan importlib (http://docs.python.org/dev/py3k/library/importlib.html). Nick benim anladığım her şeyi söyledi, ben de fazladan bilgi eklemek istiyorum.

Öncelikle, doğrudan PEP 302'ye çok fazla güvenmeyin, bunun yerine, importlib'in soyut temel sınıflar, vb. Açısından ne sağladığına bakın. Geriye dönük uyumluluk için, PEP 302 ile uyumlu olmak zorunda kaldım; Gerçek esneklik desteğini ortadan kaldırmak için kendi API'leri.

Bir diğer önemli nokta, geliştiricilere iki parça esneklik kazandırmaktır. Bunlardan biri, doğrudan dosya sistemi üzerinde ayrı ayrı dosyalar olarak başka bir şekilde kod depolayabilmesidir (bunu içe aktarma için depolama alanı olarak adlandırırım ), örneğin bu, bir zip dosyasında, sqlite veritabanında, vb. Diğer destek, kontrolün işlem kodunu bir şekilde önceden veya sonra kodlamasına izin vermek, örneğin Quixote (https://www.mems-exchange.org/software/quixote/) ve kendisine atanmamış dize değişmezlerin kullanımı. Bir değişkeni desteklemek çok daha kolay olurdu.

İkincisi nadiren ihtiyaç duyulurken, ilki destek konusunda endişelenmeniz gereken yer. Ve burası pratikte dosya sistemi etkileşimi API'lerini yeniden tanımladığınız yerdir. Bazı insanlar kodlarıyla dosya halinde depolanan varlıklara ihtiyaç duyduğundan, dosyaları okumak, dosyaları keşfetmek, vb. İçin iyi bir yol sağlamalısınız. Ayrıca, hangi veri dosyalarının kullanılabilir olduğunu bulmak, listelemek vb. İçin API bölümünü de uygulamamız gerekiyor. .

Ancak, aynı zamanda, koda özgü API'lere de ihtiyacınız vardır. Nick'in dediği gibi, bir paketin hangi modülleri içerdiğini vb. Dosya kavramını ayıkladığınız modüller ile uğraşmak için API'lere sahip olmanın bu tuhaf ikiliği var, ancak daha sonra dosya benzeri varlık verilerine erişmek için API'ler sağlamanız gerekiyor. Birini diğerinin çoğalmasını önlemek için uygulamaya koymaya çalıştığınız anda sular gerçekten bulanıklaşır (yani, insanlar yolun gerçek bir yol olamayacağına dikkat etmeden beklenen dosya yolu yapılanmasına güvenirler.) çünkü sadece bir dosyayı değil kodu içeren bir zip dosyası içindir). ŞİMDİ iki benzer API uygulamak zorunda kalacaksınız, ancak uzun vadede bunun için daha iyi olacaksınız.

Nick'in dediği gibi, çözümümüz iyi bir başlangıç ​​noktasıdır, ancak API'yi sıfırdan tasarlıyor olsam bugün nasıl yapacağım değil.


-1

PEP 302, Python içe aktarma mekanizmasına bağlanmanıza izin verir; bu, veritabanları, zip dosyaları vb. Gibi diğer kaynaklardan kod içe aktarabileceğiniz anlamına gelir.

İthalatın Python uygulamasında, bir Python ithalat uygulamasının getirilmesiyle çok yakında sadeleştirilecek olan uzun bir karmaşıklık geçmişi vardır.

Köşe davaları hakkında uzun ve sıkı düşünmeyi tavsiye etmeliyim. O zaman faydalı bir uygulama elde etme ihtimaliniz var.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.