Utilizzo delle convenzioni di denominazione per rendere 'import *' più sicuro in Python

Question

Utilizzo delle convenzioni di denominazione per rendere 'import *' più sicuro in Python

#1 da (6 voti)

3

Considera il seguente codice:

a.py

import os

def print_rand():
    print os.urandom()

E un altro modulo:

b.py

from a import *

In questo codice, finisco con una variabile os che viene importata da a . Potrei evitarlo con una piccola modifica:

a.py

import os as _os

def print_rand():
    print _os.urandom()

Poiché from a import * non rileva i membri che iniziano con un carattere di sottolineatura, b non importa il modulo os da a .

Ho pensato di farlo in alcuni dei miei codici. Non uso mai import * , ma logicamente, ha comunque un senso. (Per non parlare che non lavoro da solo sul mio codice.) os è un membro che a usa internamente; non è lì per essere esposto al mondo esterno. (Sì, sono consapevole che è possibile accedervi comunque, ma intendo solo nel senso che il trattino basso indica convenzionalmente "privato".)

Questo è qualcosa che dovrei fare? Sarebbe considerato "Pythonic", o è qualcosa che dovrei evitare in particolare? Ha importanza? (Dovrei aver chiesto su StackOverflow? Mi sembra troppo concettuale per me.)

python modules import

posta jpmc26 24.07.2013 - 05:20

fonte

1 risposta

Leggi altre domande sui tag python modules import

Esistono termini o classificazioni che descrivono il tipo di programma della riga di comando che stai scrivendo? Che tipo di licenza per mettere un progetto privato?

score 6 · Accepted Answer

Ho visto questo fatto, anche se non spesso. Non lo farei personalmente, per diversi motivi:

Nel caso di un modulo, non è il modulo stesso che è interno, è il fatto del suo utilizzo che è interno. È possibile accedere al modulo in modo abbastanza legittimo importandolo in modo esplicito, in particolare quello della libreria standard. Quindi il trattino di sottolineatura principale confonderà solo qualcuno che legge il tuo codice.
Se un utente del tuo pacchetto fa affidamento su qualcosa che non è esplicitamente menzionato nella documentazione (e probabilmente non pubblicizzerai il modulo os come parte dell'API pubblica del tuo modulo), non è davvero un tuo problema. L'ipotesi usuale in questo caso è che se vuoi usare qualcosa dalla libreria standard, lo importi da solo.
PEP8 consiglia di utilizzare __all__ per i moduli importati con import * , che elimina il problema.
L'utilizzo di import * è spesso disapprovato in ogni caso. Ad esempio, pylint si lamenta a riguardo.

Detto questo, questi non sono ancora motivi validi al 100% e potrebbero esserci casi in cui è giustificato oscurare il nome del modulo importato in questo modo.