¿Existe un formato recomendado para importaciones multilínea?

He leído que hay tres formas de codificar importaciones multilínea en python

Con barras:

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

Duplicar senteces:

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

Con paréntesis:

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

¿Existe un formato recomendado o una forma más elegante para estas declaraciones?

Personalmente, voy con paréntesis al importar más de un componente y los ordeno alfabéticamente. Al igual que:

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

Esto tiene la ventaja adicional de ver fácilmente qué componentes se han agregado / eliminado en cada confirmación o RP.

En general, es una preferencia personal y te aconsejaría que vayas con lo que mejor te parezca.

Sus ejemplos parecen provenir de PEP 328 . Allí, se propone la notación de paréntesis para exactamente este problema, así que probablemente elegiría este.

Iría con la notación de paréntesis del PEP328 con nuevas líneas agregadas antes y después de los paréntesis:

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

Este es el formato que 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, ) 

Por lo general, con Tkinter, está bien usar solo from Tkinter import * ya que el módulo solo exportará nombres que son claramente widgets.

PEP 8 no incluye ninguna convención para tal caso, por lo que supongo que depende de usted decidir cuál es la mejor opción. Se trata de la legibilidad, así que elija lo que sea que quede claro que está importando cosas desde un solo módulo.

Como todos esos nombres están disponibles en su scope, personalmente creo que las opciones 2 son las más claras, ya que puede ver los nombres importados de la mejor manera. Entonces, incluso podría dividirlo más para agrupar esos nombres que pertenecen entre sí. En su ejemplo, podría poner Tk , Frame y Canvas separado, ya que agrupan los widgets, mientras que tienen el Button y el Text separado, ya que son componentes más pequeños en una vista.