E731 non assegna un'espressione lambda, usa un def

Ricevo questo avviso pep8 ogni volta che uso espressioni lambda. Le espressioni lambda non sono consigliate? Se no perché?

La raccomandazione in PEP-8 in cui ti imbatti è:

Utilizzare sempre un'istruzione def anziché un'istruzione di assegnazione che associa un'espressione lambda direttamente a un nome.

Sì:

def f(x): return 2*x 

No:

f = lambda x: 2*x 

La prima forma indica che il nome dell'oggetto funzione risultante è specificamente 'f' invece del generico '<lambda>'. Questo è più utile per traceback e rappresentazioni di stringhe in generale. L'uso dell'istruzione di assegnazione elimina l'unico vantaggio che un'espressione lambda può offrire rispetto a un'istruzione esplicita def (ovvero che può essere incorporata in un'espressione più grande)

Assegnare lambdas ai nomi sostanzialmente duplica la funzionalità di def- e in generale, è meglio fare qualcosa in un solo modo per evitare confusione e aumentare la chiarezza.

Il caso d'uso legittimo per lambda è dove si desidera utilizzare una funzione senza assegnarla, ad esempio:

sorted(players, key=lambda player: player.rank)

In generale, l'argomento principale contro questo è che le defistruzioni comporteranno più righe di codice. La mia risposta principale sarebbe: sì, e va bene. A meno che tu non stia giocando a golf, ridurre al minimo il numero di linee non è qualcosa che dovresti fare: cerca di abbreviare in breve.

Ecco la storia, ho avuto una semplice funzione lambda che stavo usando due volte.

a = map(lambda x : x + offset, simple_list)
b = map(lambda x : x + offset, another_simple_list)

Questo è solo per la rappresentazione, ho affrontato un paio di versioni diverse di questo.

Ora, per mantenere le cose ASCIUTTE, inizio a riutilizzare questa lambda comune.

f = lambda x : x + offset
a = map(f, simple_list)
b = map(f, another_simple_list)

A questo punto il mio controllo qualità codice si lamenta del fatto che lambda sia una funzione con nome, quindi la converto in una funzione.

def f(x):
    return x + offset
a = map(f, simple_list)
b = map(f, another_simple_list)

Ora il controllore si lamenta che una funzione deve essere delimitata da una riga vuota prima e dopo.

def f(x):
    return x + offset

a = map(f, simple_list)
b = map(f, another_simple_list)

Qui abbiamo ora 6 righe di codice invece di 2 righe originali senza aumento della leggibilità e nessun aumento nell'essere pitone. A questo punto il correttore di codice si lamenta della funzione che non ha docstring.

Secondo me è meglio evitare e infrangere questa regola quando ha senso, usa il tuo giudizio.

Lattyware ha assolutamente ragione: in pratica PEP-8 vuole che tu eviti cose del genere

f = lambda x: 2 * x

e invece usa

def f(x):
    return 2 * x

Tuttavia, come indicato in un recente report di bug (agosto 2014), dichiarazioni come le seguenti sono ora conformi:

a.f = lambda x: 2 * x
a["f"] = lambda x: 2 * x

Poiché il mio correttore PEP-8 non lo implementa ancora correttamente, per il momento ho disattivato E731.

Ho anche riscontrato una situazione in cui era persino impossibile usare una funzione def (ined).

class SomeClass(object):
  # pep-8 does not allow this
  f = lambda x: x + 1  # NOQA

  def not_reachable(self, x):
    return x + 1

  @staticmethod
  def also_not_reachable(x):
    return x + 1

  @classmethod
  def also_not_reachable(cls, x):
    return x + 1

  some_mapping = {
      'object1': {'name': "Object 1", 'func': f},
      'object2': {'name': "Object 2", 'func': some_other_func},
  }

In questo caso, volevo davvero fare una mappatura appartenente alla classe. Alcuni oggetti nella mappatura necessitavano della stessa funzione. Sarebbe illogico mettere la funzione a al di fuori della classe. Non ho trovato il modo di fare riferimento a un metodo (metodo statico, metodo di classe o normale) all'interno del corpo della classe. SomeClass non esiste ancora quando viene eseguito il codice. Quindi non è nemmeno possibile fare riferimento ad esso dalla classe.