165

I have read there are three ways for coding multi-line imports in python

With slashes:

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

Duplicating senteces:

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

With parenthesis:

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

Is there a recomended format or a more elegant way for this statements?

alok
  • 1,218
  • 1
  • 12
  • 29
Manuel Alvarez
  • 2,029
  • 3
  • 14
  • 17
  • 5
    with so many imports, why not just `from Tkinter import *` ? – Inbar Rose Jan 17 '13 at 10:27
  • 3
    This is an example. Te real statement is `from data.forms import AddressEmbeddedField, PhoneEmbeddedField, MailEmbeddedField, \ WebEmbeddedField` but don't want to import all the rest of embedded fields in data.forms – Manuel Alvarez Jan 17 '13 at 10:31
  • 25
    Many reasons. E.g., you might overwrite many variables you aren't aware of. Do you know all names imported by `from Tkinter import *`? I'm not. And IDEs won't know if these names (maybe), thus they aren't able to tell if you entered an invalid name. – Thorsten Kranz Jan 17 '13 at 10:32
  • 6
    @InbarRose It's a bad habbit, look at https://stackoverflow.com/questions/3615125/should-wildcard-import-be-avoided – Yuval Pruss Jun 15 '17 at 11:19

4 Answers4

253

Personally I go with parentheses when importing more than one component and sort them alphabetically. Like so:

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

This has the added advantage of easily seeing what components have been added / removed in each commit or PR.

Overall though it's a personal preference and I would advise you to go with whatever looks best to you.

Brendan Maguire
  • 4,188
  • 4
  • 24
  • 28
  • 5
    I think the important thing is to be consistent (at least, within a given project). That will make it easy for somebody reading the code to find what's being imported without too much difficulty. – Blckknght Jan 17 '13 at 11:02
  • 1
    isort can be used to automatically format multi-line imports in different styles, see https://github.com/timothycrosley/isort#multi-line-output-modes – Motin Sep 26 '18 at 09:07
23

Your examples seem to stem from PEP 328. There, the parenthesis-notation is proposed for exactly this problem, so probably I'd choose this one.

Thorsten Kranz
  • 12,492
  • 2
  • 39
  • 56
11

I would go with the parenthesis notation from the PEP328 with newlines added before and after parentheses:

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

This is the format which Django uses:

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,
)
Max Malysh
  • 29,384
  • 19
  • 111
  • 115
  • 1
    There are no newlines added after/before the parenthesis in PEP 328? – Gandalf Saxe Aug 01 '18 at 11:04
  • @GandalfSaxe PEP 328 was about semantics (adding a new feature to the language), not about formatting. – Max Malysh Aug 01 '18 at 18:52
  • I don't quite understand then. You quote PEP 328 as having parenthesis for multi-line imports, but they have none? "I would go with the parenthesis notation from the PEP328 with newlines added before and after parentheses:" – Gandalf Saxe Aug 02 '18 at 08:00
  • PEP 328 added parenthesis notation to the language. Parenthesis notation is the ability to import multiple modules like this: `from foo import (bar, baz)`. PEP 328 says nothing about formatting. – Max Malysh Aug 02 '18 at 12:20
  • Ah ok, I see what you mean now :) – Gandalf Saxe Aug 02 '18 at 13:18
-11

Usually with Tkinter, it is okay to just use from Tkinter import * as the module will only export names that are clearly widgets.

PEP 8 does not list any conventions for such a case, so I guess it is up to you to decide what is the best option. It is all about readability, so choose whatever makes it clear that you are importing stuff from a single module.

As all those names are made available in your scope, I personally think that options 2 is the most clearest as you can see the imported names the best. You then could even split it up more to maybe group those names together that belong with each other. In your example I might put Tk, Frame and Canvas separately as they group widgets together, while having Button and Text separately as they are smaller components in a view.

poke
  • 369,085
  • 72
  • 557
  • 602
  • 16
    Never is OK to use from X import * – Tolo Palmer Jun 17 '15 at 10:41
  • 1
    @ToloPalmer Usually that is true, but for Tkinter this is generally okay, as you only import widgets; it’s even listed that way [in the library reference](https://docs.python.org/3/library/tkinter.html#tkinter-modules). And if you list the import as the first one, you should be especially safe from any conflicts. – poke Jun 17 '15 at 11:16
  • 2
    For reference, the problem with `from X import *` even for packages that use `__all__` properly is that static code analyzers like `pyflakes` can't detect undefined names if there is any `import *` since it has to assume that any undefined names was maybe imported by the `*`. – RubenLaguna Dec 11 '15 at 08:38