Stile del codice Python - righe vuote nella lunga lista

Question

Stile del codice Python - righe vuote nella lunga lista

#1 da (3 voti)
#2 da (1 voti)

1

Sono curioso, c'è un approccio standard per trattare le lunghe liste nella comunità Python, e in particolare, c'è qualche antipatia verso le righe vuote seguite dai commenti per spezzare un elenco particolarmente lungo, ad es. di tuple, o in un ditt, ecc.?

Ad esempio, sto sviluppando un'applicazione GUI in wxPython e sto definendo i mapping delle scorciatoie da tastiera a. È abbastanza Pythonic?

accelerator_table = wx.AcceleratorTable([
    # Case accelerators
    (CTRL, ord('S'), EventIds.SAVE_CASE),
    (CTRL_SHIFT, ord('S'), EventIds.RENAME_CASE),
    (CTRL, wx.WXK_DELETE, EventIds.REMOVE_CASE),
    (CTRL_SHIFT, wx.WXK_DELETE, EventIds.DELETE_CASE),

    # Project accelerators
    (CTRL_ALT_SHIFT, ord('S'), EventIds.RENAME_PROJECT),
    (ALT, wx.WXK_DELETE, EventIds.REMOVE_PROJECT),
    (ALT_SHIFT, wx.WXK_DELETE, EventIds.DELETE_PROJECT),

    # Help accelerators
    (NORMAL, wx.WXK_F1, EventIds.HELP),
    (NORMAL, wx.WXK_F2, EventIds.LAUNCH_MANUAL),
    (NORMAL, wx.WXK_F12, EventIds.ABOUT),
    ...
])

I dettagli non sono particolarmente importanti, ma mi piacerebbe scrivere in uno stile che non infastidirà altri programmatori lungo la strada, e quindi decidere in questo momento se vale la pena tenere questo schema.

Modifica: Giusto per chiarire: non intendo mettere nulla oltre quella singola riga vuota tra le sezioni nell'elenco. Sembra che dovrebbe minimizzare qualsiasi confusione da parte di qualcuno che legge il codice.

coding-style whitespace python

posta Chris Krycho 22.03.2013 - 15:05

fonte

2 risposte

1

[snip a causa di persone che non leggono la / whole / response]

Per rispondere alla tua domanda, gli spazi bianchi vanno bene per rompere le cose visivamente, ma ti consiglio che il numero di linee che usi non superi quello del numero di linee tra le altre entità nel tuo codice (come il numero di linee tra funzioni all'interno di una classe, o classi o funzioni a livello di modulo). Poiché la leggibilità di Python è basata in modo così pesante sugli spazi bianchi, l'utilizzo di più spazi bianchi in un particolare metodo per suddividere il codice interno potrebbe inizialmente dare adito a un lettore che cerca di farcela a colpo d'occhio.

Modifica in base ai commenti :

>>> accel_file = [('a','b'), ('c', 'd')]
>>> accel_project = [('e', 'f'), ('g', 'h')]
>>> 
>>> from itertools import chain
>>> list(chain(accel_file, accel_project))
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Il raggruppamento come tale consente al tuo codice di essere auto-documentato. chain è una soluzione eccessivamente complessa in questo caso particolare (stavo scrivendo codice usando al momento della risposta: P), ma potrebbe essere utile se si fa qualcosa del tipo:

accelerators = [accel_file, acces_project, ...]
list(chain(*accelerators))

Ma per il caso semplice, sarebbe preferibile la concatenazione ( + ).

risposta data 22.03.2013 - 15:18

fonte

Leggi altre domande sui tag coding-style whitespace python

Utilizzo di più versioni di siti Web (Git) Modo efficiente per confrontare gli alberi del grafico di scena

score 3 · Accepted Answer

Osservando l'approccio iniziale del PO, è immediatamente ovvio per me cosa stia facendo. Non vedo che ci siano problemi di leggibilità o di manutenibilità con questo, né vedo che viola le convenzioni o gli idiomi di Python comunemente accettati. È chiaro, e usa il minimo sintattico e le operazioni estranee per raggiungere il suo obiettivo. Raccomando di attenersi a questo approccio.

L'implementazione suggerita dalla risposta di Demian sembra creare più problemi di quanti ne risolva. Restituire una lista da una proprietà di solito non è una buona idea, perché crea un'interfaccia che apparirà identica a un attributo, ma mostrerà un comportamento bizzarro se usata come tale, ad es. t.file.extend (t.project) non farà ciò che molti utenti si aspetterebbero e "fallirebbe silenziosamente", causando bug potenzialmente confondenti.

L'OP potrebbe usare attributi di istanza o campi di classi invece di proprietà, ma non sono sicuro che un approccio orientato agli oggetti abbia molta utilità qui (cioè sembra che stia usando la sintassi di classe senza utilizzare concetti OOP reali).

Tuttavia, il suggerimento di separare l'aggregato di tuple-list in più elenchi più piccoli, che vengono quindi concatenati e passati a wx.AcceleratorTable , sembra ragionevole. L'approccio "giusto" è per lo più una questione di preferenza, anche se preferisco ancora l'approccio iniziale dell'OP perché comporta una minore manipolazione delle liste e non ha problemi di leggibilità che vedo.