E731 nie przypisuj wyrażenia lambda, użyj def

Otrzymuję to ostrzeżenie pep8 za każdym razem, gdy używam wyrażeń lambda. Czy wyrażenia lambda nie są zalecane? Jeśli nie to dlaczego?

Zalecenia w PEP-8, na które się napotykasz, to:

Zawsze używaj instrukcji def zamiast instrukcji przypisania, która wiąże wyrażenie lambda bezpośrednio z nazwą.

Tak:

def f(x): return 2*x 

Nie:

f = lambda x: 2*x 

Pierwsza forma oznacza, że ​​nazwą wynikowego obiektu funkcji jest konkretnie „f” zamiast ogólnego „<lambda>”. Jest to bardziej przydatne w przypadku śledzenia wstecznego i reprezentacji ciągów w ogóle. Zastosowanie instrukcji przypisania eliminuje jedyną korzyść, jaką wyrażenie lambda może zaoferować w stosunku do jawnej instrukcji def (tzn. Że można ją osadzić w większym wyrażeniu)

Przypisywanie lambdas do nazw w zasadzie powiela funkcjonalność def- i ogólnie najlepiej zrobić coś w jeden sposób, aby uniknąć nieporozumień i zwiększyć przejrzystość.

Uzasadnionym przypadkiem użycia dla lambda jest miejsce, w którym chcesz użyć funkcji bez przypisania jej, np .:

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

Zasadniczo głównym argumentem przeciwko temu jest to, że definstrukcje spowodują powstanie większej liczby wierszy kodu. Moja główna odpowiedź na to brzmi: tak, i jest w porządku. O ile nie grasz w golfa, minimalizowanie liczby linii nie jest czymś, co powinieneś robić: idź na skróty.

Oto historia, miałem prostą funkcję lambda, z której korzystałem dwa razy.

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

To tylko dla reprezentacji, spotkałem się z kilkoma różnymi wersjami tego.

Teraz, aby utrzymać stan NA SUCHO, zaczynam ponownie używać tej wspólnej lambda.

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

W tym momencie mój kontroler jakości kodu skarży się, że lambda jest nazwaną funkcją, więc przekształcam ją w funkcję.

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

Teraz moduł sprawdzający skarży się, że funkcja musi być ograniczona jedną pustą linią przed i po.

def f(x):
    return x + offset

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

Tutaj mamy teraz 6 wierszy kodu zamiast oryginalnych 2 wierszy bez zwiększania czytelności i bez zwiększania pythoniczności. W tym momencie narzędzie do sprawdzania kodu skarży się, że funkcja nie ma dokumentów.

Moim zdaniem tej zasady lepiej unikać i łamać, gdy ma to sens, skorzystaj z własnego osądu.

Lattyware ma absolutną rację: Zasadniczo PEP-8 chce, abyś unikał takich rzeczy

f = lambda x: 2 * x

i zamiast tego użyj

def f(x):
    return 2 * x

Jednak, jak opisano w ostatnim raporcie o błędach (sierpień 2014 r.), Następujące oświadczenia są teraz zgodne:

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

Ponieważ mój moduł sprawdzania PEP-8 jeszcze tego nie implementuje, na razie wyłączyłem E731.

Zetknąłem się również z sytuacją, w której korzystanie z funkcji def (ined) było niemożliwe.

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},
  }

W tym przypadku naprawdę chciałem stworzyć mapowanie należące do klasy. Niektóre obiekty w mapowaniu wymagały tej samej funkcji. Nielogiczne byłoby umieszczanie nazwanej funkcji poza klasą. Nie znalazłem sposobu na odwołanie się do metody (metoda statyczna, metoda klasowa lub normalna) z wnętrza klasy. SomeClass jeszcze nie istnieje po uruchomieniu kodu. Odwołanie się do tego z klasy też nie jest możliwe.