E731 не призначають лямбда-вираз, використовуйте def

Я отримую це попередження pep8, коли я використовую лямбда-вирази. Чи не рекомендуються лямбда-вирази? Якщо ні, чому?

Рекомендація в PEP-8, яку ви працюєте, це:

Завжди використовуйте оператор def замість оператора присвоєння, який прив'язує лямбда-вираз безпосередньо до імені.

Так:

def f(x): return 2*x 

Немає:

f = lambda x: 2*x 

Перша форма означає, що ім'я результуючого функціонального об'єкта конкретно 'f' замість загального '<lambda>'. Це корисніше для зворотних зворотів та подання рядків загалом. Використання оператора присвоєння виключає єдину вигоду, яку може запропонувати лямбда-вираз над явним оператором def (тобто, що він може бути вбудований у більший вираз)

Присвоєння лямбдам імен в основному просто дублює функціональність def- і взагалі, найкраще зробити щось єдиним способом, щоб уникнути плутанини та підвищення чіткості.

Законний випадок використання лямбда - це те, де ви хочете використовувати функцію, не призначаючи її, наприклад:

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

Загалом, головний аргумент проти цього полягає в тому, що у defтвердженнях з'явиться більше рядків коду. Моя основна відповідь на це була б: так, і це нормально. Якщо ви не кодуєте гольф, мінімізація кількості ліній - це не те, що вам слід робити: займіться ясним за короткий час.

Ось історія, у мене була проста лямбда-функція, яку я використовував двічі.

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

Це лише для представлення, я зіткнувся з парою різних версій цього.

Тепер, щоб утримати речі, я починаю повторно використовувати цю звичайну лямбда.

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

На даний момент моя перевірка якості коду скаржиться на те, що лямбда називається функцією, тому я перетворюю її у функцію.

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

Тепер перевірявач скаржиться, що функція повинна бути обмежена одним порожнім рядком до і після.

def f(x):
    return x + offset

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

Тут ми маємо 6 рядків коду замість оригінальних 2 рядків, не збільшуючи читабельності та не збільшуючись, будучи пітонічними. У цей момент програма перевірки коду скаржиться на те, що функція не має документації.

На мою думку, цього правила краще уникати та порушувати, коли це має сенс, використовувати своє судження.

Lattyware абсолютно прав: PEP-8 прагне, щоб ви уникали подібних речей

f = lambda x: 2 * x

і замість цього використовувати

def f(x):
    return 2 * x

Однак, як було зазначено в недавньому звіті про помилки (серпень 2014 р.), Такі твердження, як наведено нижче, тепер сумісні:

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

Оскільки моя перевірка PEP-8 ще не реалізує це правильно, я поки що вимкнув E731.

Я також зіткнувся з ситуацією, в якій навіть неможливо було використовувати функцію 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},
  }

У цьому випадку мені дуже хотілося зробити відображення, яке належало до класу. Деякі об’єкти в картографуванні потребували тієї ж функції. Було б нелогічно ставити названу функцію поза класом. Я не знайшов способу звернутися до методу (staticmethod, classmethod або normal) зсередини тіла класу. SomeClass ще не існує при запуску коду. Тому посилання на нього з класу також неможливо.