İç fonksiyonları içe aktarmak pitonik mi?

PEP 8 diyor ki:

• İçe aktarmalar her zaman, herhangi bir modül yorumundan ve belge dizgisinden hemen sonra ve modül globalleri ve sabitlerinden önce olmak üzere dosyanın en üstüne yerleştirilir.

Bazı durumlarda, PEP 8'i ihlal ediyorum. Bazen işlevlerin içindeki öğeleri içe aktarıyorum. Genel bir kural olarak, bunu yalnızca tek bir işlev içinde kullanılan bir içe aktarma varsa yaparım.

Herhangi bir görüş?

DÜZENLE (işlevleri içe aktarmayı düşünmemin nedeni iyi bir fikir olabilir):

Ana neden: Kodu daha net hale getirebilir.

• Bir işlevin koduna bakarken kendime şunu sorabilirim: "İşlev / sınıf xxx nedir?" (işlev içinde kullanılan xxx). Tüm içe aktarmalarım modülün üst kısmına gelirse, xxx'nin ne olduğunu belirlemek için oraya bakmam gerekir. Bu daha çok kullanırken bir sorundur from m import xxx. m.xxxFonksiyonu görmek muhtemelen bana daha fazlasını anlatıyor. Neyin molduğuna bağlı olarak : İyi bilinen bir üst düzey modül / paket ( import m) mi? Yoksa bir alt modül / paket ( from a.b.c import m) mi?
• Bazı durumlarda, fazladan bilginin ("xxx nedir?") Xxx kullanılan yere yakın olması, işlevin anlaşılmasını kolaylaştırabilir.

Uzun vadede, içe aktarmalarınızın çoğunun dosyanın en üstünde olmasını takdir edeceğinizi düşünüyorum, bu şekilde, modülünüzün içeri aktarması gerekenlere göre ne kadar karmaşık olduğunu bir bakışta anlayabilirsiniz.

Mevcut bir dosyaya yeni kod eklersem, genellikle içe aktarımı gerektiği yerde yaparım ve ardından kod kalırsa, içe aktarma satırını dosyanın en üstüne taşıyarak işleri daha kalıcı hale getiririm.

Bir başka nokta, ImportErrorherhangi bir kod çalıştırılmadan önce bir istisna almayı tercih ederim - bir akıl sağlığı kontrolü olarak, bu yüzden en üstte içe aktarmak için başka bir neden.

pyCheckerKullanılmayan modülleri kontrol etmek için kullanıyorum .

Bu bağlamda PEP 8'i ihlal ettiğim iki durum var:

• Dairesel içe aktarmalar: modül A, modül B'yi içe aktarır, ancak modül B'deki bir şey, modül A'ya ihtiyaç duyar (ancak bu genellikle döngüsel bağımlılığı ortadan kaldırmak için modülleri yeniden düzenlemem gerektiğinin bir işaretidir)
• Bir pdb kesme noktası eklemek: import pdb; pdb.set_trace()Bu kullanışlı b / c import pdbHata ayıklamak isteyebileceğim her modülün en üstüne koymak istemiyorum ve kesme noktasını kaldırdığımda içe aktarmayı kaldırmayı hatırlamak kolay.

Bu iki durumun dışında, her şeyi en üste koymak iyi bir fikirdir. Bağımlılıkları daha net hale getirir.

İşte kullandığımız dört ithal kullanım örneği

1. import(ve from x import yve import x as y) üstündeki

2. İthalat Seçenekleri. Tepede.

   import settings
   if setting.something:
       import this as foo
   else:
       import that as foo

3. Koşullu İthalat. JSON, XML kitaplıkları ve benzerleriyle kullanılır. Tepede.

   try:
       import this as foo
   except ImportError:
       import that as foo

4. Dinamik Alma. Şimdiye kadar bunun sadece bir örneğine sahibiz.

   import settings
   module_stuff = {}
   module= __import__( settings.some_module, module_stuff )
   x = module_stuff['x']

   Bu dinamik içe aktarmanın kod getirmediğini, ancak Python'da yazılmış karmaşık veri yapılarını getirdiğini unutmayın. El ile toparlamamız dışında, turşu bir veri parçası gibi.

   Bu aynı zamanda bir modülün tepesinde aşağı yukarı

Kodu daha net hale getirmek için yaptıklarımız:

• Modülleri kısa tutun.

• Tüm içe aktarmalarımı modülün en üstünde tutuyorsam, adın ne olduğunu belirlemek için oraya gitmem gerekiyor. Modül kısaysa, bunu yapmak kolaydır.

• Bazı durumlarda, bir ismin kullanıldığı yere yakın bu ekstra bilgiye sahip olmak, işlevin anlaşılmasını kolaylaştırabilir. Modül kısaysa, bunu yapmak kolaydır.

Unutulmaması gereken bir şey var: gereksiz ithalat performans sorunlarına neden olabilir. Dolayısıyla, bu sıklıkla çağrılacak bir işlevse, içe aktarmayı en üste koymanız daha iyi olur. Tabii bu olan bir işlev içinde ithal bir dosyanın en üstünde ithal daha olduğunu açıkça ifade edilmesi için geçerli bir durum var eğer öyleyse, bir optimizasyon çoğu durumda koz performans söyledi.

IronPython yapıyorsanız, içerideki işlevleri içe aktarmanın daha iyi olduğu söylendi (çünkü IronPython'da kod derlemek yavaş olabilir). Böylece, o zaman iç işlevleri içe aktarmanın bir yolunu bulabilirsin. Ama bunun dışında, geleneğe karşı savaşmanın buna değmediğini iddia ediyorum.

Genel bir kural olarak, bunu yalnızca tek bir işlev içinde kullanılan bir içe aktarma varsa yaparım.

Vurgulamak istediğim bir diğer nokta da bunun potansiyel bir bakım sorunu olabileceğidir. Daha önce yalnızca bir işlev tarafından kullanılmış bir modülü kullanan bir işlev eklerseniz ne olur? İçe aktarımı dosyanın en üstüne eklemeyi hatırlayacak mısınız? Yoksa ithalat için her bir işlevi mi tarayacaksınız?

FWIW, bir işlevin içine aktarmanın anlamlı olduğu durumlar vardır. Örneğin, cx_Oracle'da dili ayarlamak istiyorsanız , içe aktarılmadan önce bir NLS _LANG ortam değişkeni ayarlamanız gerekir . Bu nedenle, aşağıdaki gibi bir kod görebilirsiniz:

import os

oracle = None

def InitializeOracle(lang):
    global oracle
    os.environ['NLS_LANG'] = lang
    import cx_Oracle
    oracle = cx_Oracle

Kendi kendini test eden modüller için bu kuralı daha önce ihlal ettim. Yani, normalde sadece destek için kullanılırlar, ancak onlar için bir ana tanımlıyorum, böylece onları kendi başlarına çalıştırırsanız, işlevselliklerini test edebilirsiniz. Bu durumda bazen içe aktarıyorum getoptve cmdsadece esas olarak, çünkü kodu okuyan birine, bu modüllerin modülün normal çalışmasıyla hiçbir ilgisi olmadığı ve sadece test için dahil edildiklerinin açık olmasını istiyorum.

Modülü iki kez yüklemeyle ilgili sorudan geliyor - Neden ikisi birden olmasın?

Komut dosyasının üst kısmındaki bir içe aktarma, bağımlılıkları ve işlevdeki başka bir içe aktarma ile bu işlevi daha atomik hale getirirken, görünürde herhangi bir performans dezavantajına neden olmaz, çünkü ardışık içe aktarma ucuzdur.

Olduğu importve olmadığı sürece from x import *, onları en üste koymalısın. Global isim alanına sadece bir isim ekler ve siz PEP 8'e bağlı kalırsınız. Ayrıca, daha sonra başka bir yerde ihtiyacınız olursa, herhangi bir şeyi hareket ettirmeniz gerekmez.

Önemli değil, ancak neredeyse hiçbir fark olmadığından, PEP 8'in söylediği şeyi yapmayı öneririm.

Sqlalchemy'de kullanılan alternatif yaklaşıma bir göz atın: bağımlılık ekleme:

@util.dependencies("sqlalchemy.orm.query")
def merge_result(query, *args):
    #...
    query.Query(...)

İçe aktarılan kitaplığın bir dekoratörde nasıl bildirildiğine ve işleve argüman olarak nasıl aktarıldığına dikkat edin !

Bu yaklaşım, kodu daha temiz hale getirir ve ayrıca bir ifadeden 4,5 kat daha hızlı çalışır import!

Karşılaştırma: https://gist.github.com/kolypto/589e84fbcfb6312532658df2fabdb796

Hem 'normal' modüller olan hem de yürütülebilen modüllerde (yani bir if __name__ == '__main__': bölüme sahip) modüllerde, genellikle yalnızca ana bölüm içindeki modülü çalıştırırken kullanılan modülleri içe aktarırım.

Misal:

def really_useful_function(data):
    ...


def main():
    from pathlib import Path
    from argparse import ArgumentParser
    from dataloader import load_data_from_directory

    parser = ArgumentParser()
    parser.add_argument('directory')
    args = parser.parse_args()
    data = load_data_from_directory(Path(args.directory))
    print(really_useful_function(data)


if __name__ == '__main__':
    main()

importNadiren kullanılan işlevlerin içinde yararlı olabileceği başka bir (muhtemelen "köşe") durum daha var: başlangıç ​​süresini kısaltın.

Bir seri hattan komutları kabul eden ve muhtemelen çok karmaşık işlemler gerçekleştiren küçük bir IoT sunucusunda çalışan oldukça karmaşık bir programla bu duvara bir kez çarptım.

Tüm içe aktarımların sunucu başlatılmadan önce işlenmesi importanlamına gelen ifadelerin dosyaların üstüne yerleştirilmesi ; çünkü liste dahil , , ve diğer "ağır ağırlıklar" (ve SoC çok güçlü değildi) bu demek dakika ilk talimat önce aslında idam edildi.importjinja2lxmlsignxml

OTOH, çoğu ithalatı işlevlere yerleştirerek, sunucunun seri hatta saniyeler içinde "canlı" olmasını sağladım. Tabii ki, modüllere gerçekten ihtiyaç duyulduğunda bedelini ödemem gerekiyordu (Not: bu, importboşta kalma süresinde s yapan bir arka plan görevi oluşturarak da hafifletilebilir ).