Importazioni comuni tra molti script nel progetto Python

Question

Importazioni comuni tra molti script nel progetto Python

#1 da (1 voti)

6

Sto scrivendo uno script di installazione automatica per un gruppo di software, in Python. Lo scopo è che lo script recuperi i file compressi da una directory e installa / configura ogni utilità o applicazione caso per caso.

Dato che ognuno di questi richiede un trattamento speciale (e quando non è richiesto è un'eccezione e preferirei essere pronto nel caso in cui abbia bisogno di un trattamento speciale in futuro), ho deciso per avere un file .py separato per ciascuno di essi, con lo script principale che rileva automaticamente quale utilizzare in base alla corrispondenza dei nomi, le cui regole si trovano in un file .json centrale.

Molti di questi script specifici richiedono più o meno le stesse importazioni, oltre a quelli specifici di quel file. Così ho deciso che ha senso, proprio come facciamo in linguaggi come C, avere uno script "header" che importa i moduli usati di frequente e importalo in tutti gli script minori e specifici.

Tuttavia , dopo aver letto diverse domande su SO ( qui , qui , qui e qui sono alcuni) sembra che il consenso sia che non si dovrebbe mai farlo e invece importare esplicitamente moduli su ogni file, come richiesto. I motivi indicati sono:

È esplicito e in linea con la filosofia di design di Python
Rende più facile trovare le dipendenze con una semplice ricerca di testo

Ho preso in considerazione questi dati ma non riesco a decidere se si applicano nel mio caso. Avrò 50-100 file diversi, ognuno dei quali richiede alcune importazioni comuni e alcune importazioni specifiche per quel file. Sembra in linea con "non ripeterti" per mettere tutte le importazioni comuni in un file e importarlo. Sembra anche meno soggetto a errori (cosa succede se cambio in un modulo diverso con la stessa interfaccia e ho solo bisogno di cambiare l'istruzione import ? Se è in un posto, io so è corretto ovunque, altrimenti avrei bisogno di cambiarlo in ogni file).

Indipendentemente dai dettagli di questo specifico progetto, in generale, c'è sempre un buon caso da fare per un file di importazione comune in Python?

coding-style programming-practices python

posta mechalynx 27.04.2016 - 21:10

fonte

1 risposta

Leggi altre domande sui tag coding-style programming-practices python

Ho bisogno di sapere come funziona Ajax da quando Asp.net mi fornisce UpdatePanel [chiuso] Distribuzione ottimale del carico con carico di lavoro massimo

score 1 · Answer 1

Se stai scrivendo il codice che richiede una libreria, l'importazione per la libreria è necessariamente meno codice rispetto al codice che utilizza tale libreria. Quando si mettono insieme i due nello stesso file, è più probabile che i cambiamenti in uno si traducano nel ricordare di fare l'altro. In particolare se l'editor utilizza Pyflakes per applicare la conformità PEP e quindi rileva l'importazione non utilizzata.

Se stai scrivendo molti script che sono molto simili, le dichiarazioni di importazione comuni saranno l'ultimo dei tuoi problemi. Invece muovere il maggior numero possibile di codice comune in un modulo comune dove ENTRAMBE le importazioni E il codice che ha bisogno di quelle importazioni vive. È possibile implementare le sovrascritture degli script con una combinazione di configurazione e sottoclassi e quelle sottoclassi saranno molto più brevi a causa della quantità di elementi comuni nello script. Questo andrà più lontano verso la rimozione della duplicazione del codice rispetto a una procedura di importazione magica e sorprenderà i maintainer di meno.