Esiste un formato consigliato per l'importazione su più righe?


114

Ho letto che ci sono tre modi per codificare le importazioni multilinea in Python

Con barre:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text, \
    LEFT, DISABLED, NORMAL, RIDGE, END

Senteces duplicati:

from Tkinter import Tk, Frame, Button, Entry, Canvas, Text
from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END

Con parentesi:

from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
    LEFT, DISABLED, NORMAL, RIDGE, END)

Esiste un formato consigliato o un modo più elegante per queste affermazioni?


3
con così tante importazioni, perché non solo from Tkinter import *?
Inbar Rose

2
Questo è un esempio. La vera affermazione è from data.forms import AddressEmbeddedField, PhoneEmbeddedField, MailEmbeddedField, \ WebEmbeddedFieldma non voglio importare tutti gli altri campi incorporati in data.forms
Manuel Alvarez

19
Molte ragioni. Ad esempio, potresti sovrascrivere molte variabili di cui non sei a conoscenza. Conosci tutti i nomi importati da from Tkinter import *? Non sono. E gli IDE non sapranno se questi nomi (forse), quindi non sono in grado di dire se hai inserito un nome non valido.
Thorsten Kranz

2
@InbarRose E 'una cattiva habbit, sguardo stackoverflow.com/questions/3615125/...
Yuval Pruss

Risposte:


161

Personalmente vado con le parentesi quando importi più di un componente e li ordino alfabeticamente. Così:

from Tkinter import (
    Button,
    Canvas,
    DISABLED,
    END,
    Entry,
    Frame,
    LEFT,
    NORMAL,
    RIDGE,
    Text,
    Tk,
)

Questo ha l'ulteriore vantaggio di vedere facilmente quali componenti sono stati aggiunti / rimossi in ogni commit o PR.

Nel complesso però è una preferenza personale e ti consiglierei di andare con quello che ti sembra meglio.


3
Penso che la cosa importante sia essere coerenti (almeno, all'interno di un dato progetto). Ciò renderà facile per qualcuno che legge il codice trovare ciò che viene importato senza troppe difficoltà.
Blckknght

1
isort può essere utilizzato per formattare automaticamente le importazioni multilinea in stili diversi, vedere github.com/timothycrosley/isort#multi-line-output-modes
Motin

16

I tuoi esempi sembrano derivare da PEP 328 . Lì, la notazione tra parentesi viene proposta esattamente per questo problema, quindi probabilmente sceglierei questo.


4

Vorrei andare con la notazione tra parentesi dal PEP328 con le nuove righe aggiunte prima e dopo le parentesi:

from Tkinter import (
    Tk, Frame, Button, Entry, Canvas, Text, 
    LEFT, DISABLED, NORMAL, RIDGE, END
)

Questo è il formato che Django usa:

from django.test.client import Client, RequestFactory
from django.test.testcases import (
    LiveServerTestCase, SimpleTestCase, TestCase, TransactionTestCase,
    skipIfDBFeature, skipUnlessAnyDBFeature, skipUnlessDBFeature,
)
from django.test.utils import (
    ignore_warnings, modify_settings, override_settings,
    override_system_checks, tag,
)

Non ci sono nuove righe aggiunte dopo / prima delle parentesi in PEP 328?
Gandalf Saxe

@GandalfSaxe PEP 328 riguardava la semantica (l'aggiunta di una nuova funzionalità al linguaggio), non la formattazione.
Max Malysh

Allora non capisco bene. Citi PEP 328 come parentesi per le importazioni multilinea, ma non ne hanno? "Vorrei andare con la notazione tra parentesi dal PEP328 con i nuovi caratteri aggiunti prima e dopo le parentesi:"
Gandalf Saxe

PEP 328 ha aggiunto la notazione tra parentesi alla lingua. Parentesi notazione è la possibilità di importare più moduli in questo modo: from foo import (bar, baz). PEP 328 non dice nulla sulla formattazione.
Max Malysh

Ah ok, capisco cosa intendi ora :)
Gandalf Saxe

-4

Di solito con Tkinter, va bene usarlo semplicemente from Tkinter import *poiché il modulo esporterà solo nomi che sono chiaramente widget.

PEP 8 non elenca alcuna convenzione per un caso del genere, quindi immagino che spetti a te decidere quale sia l'opzione migliore. È tutta una questione di leggibilità, quindi scegli quello che rende chiaro che stai importando cose da un singolo modulo.

Poiché tutti questi nomi sono disponibili nel tuo ambito, personalmente penso che l'opzione 2 sia la più chiara in quanto puoi vedere i nomi importati al meglio. Quindi potresti anche dividerlo di più per raggruppare insieme quei nomi che si appartengono tra loro. Nel tuo esempio potrei mettere Tk, Framee Canvasseparatamente mentre raggruppano i widget insieme, pur avendo Buttone Textseparatamente poiché sono componenti più piccoli in una vista.


11
Non va mai bene usare da X import *
Tolo Palmer

1
@ToloPalmer Di solito è vero, ma per Tkinter generalmente va bene, dato che importi solo widget; è anche elencato in questo modo nel riferimento della libreria . E se elenchi l'importazione come la prima, dovresti essere particolarmente al sicuro da eventuali conflitti.
colpisci il

1
Per riferimento, il problema from X import *anche per i pacchetti che utilizzano __all__correttamente è che analizzatori di codice statico come pyflakesnon possono rilevare nomi indefiniti se ce ne sono import *poiché si deve presumere che eventuali nomi indefiniti siano stati importati da *.
RubenLaguna
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.