понимание списка против лямбда + фильтр
Проблема возникает только при щелчке редактируемого поля, поэтому присоединяем к этому элементу обычный обработчик click, который отменит распространение события (, см. stopPropagation ), и установит тайм-аут (setTimeout(...)), например, 600 мс ( время по умолчанию между двумя щелчками, которое считается dbl-кликом, составляет 500 мс [src] ). Если к этому моменту dblclick не произошло (вы можете иметь var, доступный в обоих обработчиках событий, который действует как флаг для обнаружения этого), тогда вы можете предположить, что пользователь хочет развернуть строку и продолжить это действие. ..
IMO, вам следует подумать об этом. Увы, один обработчик кликов не может знать, хочет ли пользователь дважды щелкнуть.
Я предлагаю сделать одно действие одним действием и просто не распространяться из редактируемого поля при нажатии.
5 ответов
Странно, насколько красота различается у разных людей. Я считаю, что понимание списка намного яснее, чем фильтр + лямбда , но используйте то, что вам будет проще.
Есть две вещи, которые могут замедлить использование фильтра .
Во-первых, это накладные расходы на вызов функции: как только вы используете функцию Python (созданную с помощью def или лямбда ), вероятно, что фильтр будет работать медленнее, чем список понимание. Почти наверняка этого недостаточно, и вам не следует много думать о производительности, пока вы не рассчитаете время своего кода и не обнаружите, что это узкое место, но разница будет.
Другие накладные расходы, которые могут возникнуть, - это то, что лямбда-функция принудительно обращается к переменной с ограниченной областью действия ( значение ). Это медленнее, чем доступ к локальной переменной, а в Python 2.x понимание списка обращается только к локальным переменным. Если вы используете Python 3.x, понимание списка выполняется в отдельной функции, поэтому он также будет получать доступ к значению через замыкание, и это различие не будет применяться.
Другой вариант, который следует рассмотреть, - использовать генератор вместо понимания списка:
def filterbyvalue(seq, value):
for el in seq:
if el.attribute==value: yield el
Затем в вашем основном коде (где действительно важна удобочитаемость) вы заменили понимание списка и фильтр на многозначительное имя функции. .
Хотя фильтр может быть «более быстрым способом», «питонический способ» не будет заботиться о таких вещах, если производительность не является абсолютно критичной (в этом случае вы бы не использовали Python!) .
Это несколько религиозный вопрос в Python. Несмотря на то, что Гвидо рассматривал возможность удаления map, filter и reduce из Python 3, это вызвало достаточную реакцию, и в итоге только reduce был перенесен из built-ins в functools.reduce.
Лично я считаю, что списковые понимания легче читать. Из выражения [i for i in list if i.attribute == value] более ясно, что происходит, поскольку все поведение лежит на поверхности, а не внутри функции фильтрации.
Я бы не стал сильно беспокоиться о разнице в производительности между двумя подходами, поскольку она незначительна. Я бы оптимизировал это только в том случае, если бы это оказалось узким местом в вашем приложении, что маловероятно.
Также, поскольку BDFL захотел filter убрать из языка, то, конечно, это автоматически делает понимание списков более питоническим ;-)
Я считаю второй способ более читаемым. Он сообщает вам, в чем именно заключается намерение: отфильтровать список.
PS: не используйте «список» в качестве имени переменной
обычно фильтр немного быстрее при использовании встроенной функции.
Я ожидаю, что в вашем случае понимание списка будет немного быстрее