Python: Perché 'da <module> importazione *' deve essere vietato?

Question

Se vi capita di avere

from <module> import * 

nel bel mezzo del programma (o modulo), si otterrebbe l'avvertimento:

/tmp/foo:100: SyntaxWarning: import * only allowed at module level 

capisco perché import * è sconsigliato in generale (invisibilità namespace) , ma ci sono molte situazioni in cui sarebbe conveniente, specialmente dove il codice non è condiviso con nessuno.

Quindi, qualcuno può spiegare con precisione in dettaglio perché from <module> import * dovrebbe essere vietato in tutti i casi possibili?

Answer 1

credo da "nel mezzo del programma" si sta parlando di un'importazione all'interno una definizione di funzione:

def f(): 
    from module import * # not allowed 

Ciò non è consentito perché renderebbe l'ottimizzazione del corpo della funzione troppo difficile. L'implementazione Python vuole conoscere tutti i nomi delle variabili locali della funzione quando esso calcola in byte una funzione, in modo che possa ottimizzare i riferimenti variabili nelle operazioni sullo stack operand della macchina virtuale (CPython) o almeno nello slot variabile locale operazioni piuttosto che ricerche nei namespace esterni. Se si potesse scaricare l'intero contenuto di un modulo nello spazio dei nomi locale di una funzione, il compilatore dovrebbe assumere che il nome nella funzione potrebbe riferirsi a un modulo globale, poiché l'elenco di nomi introdotto da from module import * è solo conosciuto in fase di esecuzione.

Mettere from module import *in tra dichiarazioni di livello superiore è stile povero, ma è consentito:

def f(): 
    ... 

from module import * 

def g(): 
    ... 

EDIT aprile 2013: Mentre cerca in qualcosa d'altro, ho scoperto che questa restrizione è stata introdotta in Python 2.1, come conseguenza dello "Nested Scopes" feature (PEP 227). Citando dal link:

effetto

Un lato del cambiamento è che le dichiarazioni from module import * e exec sono state fatte illegale all'interno di un insieme di funzioni determinate condizioni. Il manuale di riferimento di Python ha affermato che from module import * è legale solo al livello più alto di un modulo, ma l'interprete CPython non l'ha mai applicato prima. Come parte dell'implementazione degli ambiti nidificati, il compilatore che trasforma il sorgente Python in bytecode deve generare un codice diverso per accedere alle variabili in un ambito di contenimento. from module import * e exec rendono impossibile al compilatore di capirlo, perché aggiungono nomi allo spazio dei nomi locale che sono inconoscibili in fase di compilazione. Pertanto, se una funzione contiene le definizioni di funzione o le espressioni lambda con variabili libere, il compilatore lo contrassegnerà sollevando un'eccezione SyntaxError.

Questo chiarisce il comportamento di Python 3.x vs 2. discusso nei commenti. È sempre contrario alle specifiche del linguaggio, ma CPython 2.1 a 2.7 emette un errore per from module import * all'interno di una funzione solo se può influire sulla capacità del compilatore di sapere se una variabile esegue il binding localmente o in un ambito di contenimento. In 3.x è stato promosso a un errore incondizionato.

SON OF EDIT: ... e apparentemente flashk lo ha sottolineato anni fa in un'altra risposta, citando lo stesso paragrafo di "Novità in Python 2.1" ancora. Lo fai andare adesso.

Answer 2

La release notes for Python 2.1 sembrano spiegare perché questa limitazione esiste:

effetto

Un lato del cambiamento è che i dal modulo di importazione * e exec dichiarazioni sono state fatte illegale all'interno di un ambito di funzione a determinate condizioni. Il manuale di riferimento Python ha affermato che dal modulo l'importazione * è legale solo al livello superiore di un modulo, ma l'interprete CPython non ha mai applicato prima questo . Come parte dell'implementazione degli ambiti nidificati, il compilatore che trasforma in byte bytecode in Python ha variabili per accedere alle variabili in un ambito di contenimento. da modulo import * ed exec lo rendono impossibile per il compilatore di figura , perché aggiungono nomi a lo spazio dei nomi locale che è inconoscibile al momento della compilazione. Pertanto, se una funzione contiene le definizioni o le espressioni lambda con le variabili libere , il compilatore contrassegnerà sollevando un'eccezione SyntaxError .

Answer 3

Non è affatto vietato. Funziona bene, ma ricevi un avvertimento perché è generalmente una cattiva idea (per ragioni che sono state fatte ad altri). Puoi, se vuoi, sopprimere l'avvertimento; il modulo di avvertimenti è ciò che vuoi per quello.

Answer 4

A qualsiasi livello lessicale, from amodule import * è un "sembrava una buona idea, al momento" decisione di progettazione che si è dimostrato un vero e proprio disastro nella vita reale, con la possibile eccezione di esplorazione a portata di mano al prompt interprete interattivo (anche allora , Non ci sto troppo caldo - import module as m obbliga solo due caratteri in più ad usare nomi qualificati invece [[solo un prefisso m.]], e i nomi qualificati sono sempre più nitidi e flessibili dei nomi dei baristi, per non parlare del grande utilità in situazioni interattive esplorative di avere m disponibile per help(m), reload(m) e simili!).

Questo costrutto lacerato lo rende molto difficile, per la persona povera che legge il codice (spesso in un tentativo fallito di aiutarlo a debuggarlo) per capire da dove provengono nomi misteriosi - impossibile, se il costrutto viene usato di più di una volta a livello lessicale; ma anche se usato una sola volta, costringe a rileggere laboriosamente l'intero modulo ogni volta prima che uno possa convincersi che, sì, quel barname in disordine deve provenire dal modulo.

Inoltre, gli autori dei moduli di solito non vanno nei guai estremi necessari per "supportare" l'odioso costrutto in questione. Se da qualche parte nel tuo codice hai, per esempio, un uso di sys.argv (e uno import sys nella parte più alta del tuo modulo, ovviamente), come fai a sapere che sys è il modulo che dovrebbe essere ... o alcuni completamente diverso uno (o un non modulo) proveniente dallo ... import *?!Moltiplicate quello con tutti i nomi qualificati che state usando e la miseria è l'unico risultato finale - quello, e misteriosi bug che richiedono un debug lungo e laborioso (di solito con l'aiuto riluttante di qualcuno che fa "get" Python ... ! -).

All'interno di una funzione, un modo per aggiungere e ignorare nomi locali arbitrari sarebbe anche peggio. Come elementare ma cruciale ottimizzazione, il compilatore Python controlla il corpo della funzione per qualsiasi assegnazione o altre istruzioni di binding su ogni barename, e considera "local" quei nomi che vede così assegnati (gli altri devono essere globali o built-in). Con un import * (proprio come con un exec somestring senza dict esplicito da utilizzare come spazi dei nomi), improvvisamente diventa un mistero totale quali nomi sono locali, quali nomi sono globali, quindi il compilatore povero dovrebbe ricorrere alla strategia più lenta possibile per ogni ricerca del nome, usando un dict per le variabili locali (invece del "vettore" compatto che normalmente utilizza) e eseguendo fino a tre ditt di look-up per ogni barename a cui si fa riferimento, più e più volte.

Passare a qualsiasi prompt interattivo Python. Digitare import this. Cosa vedi? Lo Zen di Python. Qual è l'ultimo e probabilmente il più grande pezzo di saggezza in quel testo ...?

Gli spazi dei nomi sono una delle grandi idee - facciamolo di più!

Forzando l'uso di barenames cui nomi qualificati sono così di gran lunga preferibile, si sta essenzialmente facendo il contrario di questo saggio raccomandazione molto : invece di ammirare la grandezza e honkingtude di spazi dei nomi, e fare di più di quelli, sei che scompone due spazi dei nomi perfettamente funzionanti e pronti per l'uso (quello del modulo che stai importando e quello dell'ambito lessicale in cui lo stai importando) per creare un singolo, empio, caos buggy, lento, rigido, inutilizzabile.

Se potessi tornare indietro e cambiare uno decisione di progettazione iniziale in Python (si tratta di una scelta difficile, perché l'uso di def e soprattutto per quello che lambda Javascript così chiama molto di più essere letti function è un secondo vicino ;-), Vorrei cancellare retroattivamente l'idea di import * dalla mente di Guido. Nessuna quantità di presunta convenienza per l'esplorazione al prompt interattivo in grado di bilanciare la quantità del male è battuto ... -!)

Answer 5

altri hanno dato risposte approfondite, ti darò una risposta breve panoramica della mia comprensione .. quando usi da te lo stai facendo così puoi chiamare direttamente qualsiasi funzione in quel modulo che hai importato senza fare modulename.functioname (puoi semplicemente chiamare "functionname") questo crea problemi se hai 2 funzioni con lo stesso nome in diversi moduli e può anche creare confusione quando si ha a che fare con molte funzioni perché non si conosce a quale oggetto/modulo appartiene (dal punto di vista di qualcuno che sta guardando codice già scritto che non ha familiarità con esso)

Answer 6

Non è proibito, perché ...

... è a portata di mano per gli script di shell veloci e esplorare.

...ma non si dovrebbe tenere in qualsiasi codice serio

1. può portare a importare nomi che non si conoscono e cancellare nomi locali
2. non si può sapere che cosa è in uso nel codice, è difficile di conoscere uno script dipendenze
3. completamenti codice non funzionerà correttamente più
4. IDE convenienti controlli come "questo var non è stato dichiarato" non può più lavorare
5. lo rendono più facile creare le importazioni circolari