scrivere librerie python: struttura, denominazione e importazione best practice

Question

Diciamo che devo scrivere diverse librerie di piccole e medie dimensioni per la mia azienda.

Ha senso, in modo divinatorio, di utilizzare il metodo Java ed il prefisso tutti con un pacchetto comune di alto livello (ahem, modulo) come realizzare la seguente struttura:

mycompany.mylibrary1.moduleA 
mycompany.mylibrary1.moduleB.moduleD 
mycompany.mylibrary2.moduleC 

o è meglio andare solo per:

mylibrary1.moduleA 
mylibrary1.moduleB.moduleD 
mylibrary2.moduleC 

vedo che la maggior parte delle volte il 2 ° approccio è utilizzato, ma ero alla ricerca di una conferma (o non) che è la strada da percorrere.

io non ho trovato nulla a questo proposito in PEP 008, accanto:

Le convenzioni di denominazione della biblioteca di Python sono un po 'di confusione, in modo da non arriveremo mai questo del tutto coerente [...]

e quindi otteniamo solo i moduli e le indicazioni classe di denominazione, nonché il fatto che relative importazioni sono scoraggiati.

Il fatto che assolute importazioni importazioni siano la strada da percorrere, prendere la decisione su come si organizzano le librerie è davvero importante (e non sono qui per discutere se evitare importazioni relative è buono o cattivo).

Mi piace l'approccio Java che assegna un nome a tutte le tue librerie, ma ho l'impressione che non sia pitonico ... Qual è il modo consigliato di andare?

PS. Mentre in generale le domande sulle "migliori pratiche" sono considerate come soggettive su SO, in Python l'esistenza del PEP le rende a mio avviso molto obiettive! Anche se la risposta potrebbe essere ... non ci sono le migliori pratiche per organizzare le tue librerie ..

Answer 1

C'è un problema cognitivo con importazioni e nomi python. Dato che ci sono così tanti diversi tipi di oggetti di primo ordine (primitive, moduli, classi, funzioni, classi che fingono di essere moduli, moduli che fingono di essere oggetti, eccetera) le persone tendono ad usare la notazione a punti per indicare che un'entità ha " arrivato "da una fonte esterna. Così

import foo.bar 
e = foo.bar.make_entity() 

è sentito di essere più chiaro di

from foo.bar import make_entity 
e = make_entity() 

Tuttavia, questo significa che si dovrà spesso necessario digitare il percorso completo di tutto ciò che è necessario accedere. "com.example.some.lib.module.frobnicate() diventa fastidioso rapidamente.Così, una biblioteca educata fornisce un nome ragionevolmente breve per il suo accesso