Играя в адвоката дьявола. Я не понимаю, почему эта идиома считается питонической. «Явное лучше, чем неявное», верно? Эта проверка не кажется очень точной в отношении того, что именно проверяется.

@JamesMcMahon - это компромисс между явностью и гибкостью типов. как правило, «быть откровенным» означает не делать «волшебных» вещей. с другой стороны, «утиная типизация» означает работу с более общими интерфейсами, а не явную проверку типов. так что что-то вроде if a == [] форсирует определенный тип (() == [] - это False). здесь общий консенсус, похоже, заключается в том, что утиная печать побеждает (по сути, говоря, что __nonzero__ - это интерфейс для тестирования пустоты docs.python.org/reference/datamodel.html#object.__nonzero__)

Этот метод не работает с массивами numpy .. поэтому я думаю, что, если len (a) == 0 предпочтительнее как с точки зрения «утиной печати», так и с точки зрения неявности.

Канонический способ узнать, является ли массив в C пустым, - это разыменовать первый элемент и посмотреть, является ли он нулевым, предполагая, что массив завершается нулем. В противном случае сравнение его длины с нулем совершенно неэффективно, если массив имеет значительный размер. Кроме того, как правило, вы не выделяете память для пустого массива (указатель остается нулевым), поэтому нет смысла пытаться получить его длину. Я не говорю, что len (a) == 0 - не лучший способ сделать это, просто он не кричит мне «C», когда я его вижу.

@sleblanc Я никогда не видел массив с завершающим нулем в c за пределами реализации строки, общий случай - это не завершение нулем. «сравнение его длины с нулем совершенно неэффективно» неверно, не существует реализации c, где это стоило бы больше пары циклов. Сравнение длины массива с 0 для определения пустоты является стандартной практикой в ​​c и почти во всех языках, на которые влияет c (C++, java, C# и т. д.).

@BrennenSprimont, если он не завершается нулем, значит, вы уже знаете длину, хранится ли она в отдельной переменной или ваш массив завернут в какой-то контейнер, который отслеживает длину. C++, Java, C# имеют такие контейнеры и эффективно реализуют некоторый метод "длины". C имеет нет такой вещи, вам придется свернуть свой собственный. Статически выделенные массивы C - это просто указатели на область памяти, в которой гарантированно будет достаточно места для хранения запрошенного вами объема данных. В C нет ничего, что сообщило бы вам, сколько вы уже заполнили это пространство.

Другой аналогичный способ: print (bool(not a))

Если вы используете это для настраиваемого объекта, то есть «if not customObject», убедитесь, что вы реализовали метод len в определении класса настраиваемого объекта, иначе он будет оцениваться как False даже для пустого объекта.

Простая вариация в одну строку: 'Empty' if not a else 'Full' вот так: 'Empty' if not [1] else 'Full'

При использовании Numpy и в соответствии с его документацией вы должны использовать: array.size> 0 В противном случае у вас будет следующее сообщение. DeprecationWarning: The truth value of an empty array is ambiguous. Returning False, but in future this will result in an error. Use array.size > 0 to check that an array is not empty.

Исходя из языка, который претендует на звание своего рода поэзии, этот механизм - чистый мусор. Семантически быть пустым очень отличается от того, чтобы быть пустым.

Мы тоже можем использовать if (len(a) == 0):

@ Mr.WorshipMe: if len(a) == 0 также не работает для массивов NumPy, потому что он не работает для таких фигур, как (5, 0). Массив 5 на 0 пуст, но имеет длину 5. Проверкой массива NumPy будет a.size == 0 (или not a.size), что не работает для списка.

Он напечатает, что a пуст, а a = None считается пустым, потому что not bool(None) == True.

Если кто-то сочтет это полезным, я создал учебное пособие на YouTube, в котором сравниваются различные способы проверить, пуст ли список youtube.com/watch?v=8V88bl3tuBQ

Похоже на разработчика Python, влюбленного в Ruby. ржунимагу

Это неявно и, следовательно, непифонично, поскольку «явное лучше, чем неявное».

if bool([]) #Falseif bool([1,2,3]) #True Мне кажется, проще всего использовать bool(list_name).

@ThunderPhoenix - можно также просто использовать if len (a):, поскольку значение> ноль будет оцениваться как True ... ;-)

Замечательно, что кто-то поднял вопрос, что это неприменимо для массива numpy, но давайте сосредоточимся на вопросе How do I check if a list is empty?. Мы просто хотим проверить, пуст список или нет. Я думаю, что этот ответ хорош и в значительной степени питонический, и я полностью согласен с sleblanc.

Думая об этом, питон уже имеет наши спины, он уже дает нам истинное значение последовательностей, таких как строки, списки, кортежи, как указано ниже. Таким образом, мы можем просто использовать его DIRECTLY и не получать len(), чтобы проверить, является ли он EMPTY.

@andrewcooke Я пришел к выводу, что здесь используется тип утки, потому что он общий и не проверяет тип.

Мне интересно, что вопрос касается проверки того, был ли передан пустой список, и многие непреклонны в том, что решение не должно различать переданный пустой список и переданный None. Или 0 передается. Не зная, какие другие возможные значения могут быть переданы и представляют ли каждое из них отдельный случай, который необходимо обработать, мы не можем предположить, что уместен более широкий тест.

Странно, как [] == False оценит как False, хотя

@information_interchange Если вы хотите явно проверить истинность значения, используйте bool(). bool([]) == False будет соответствовать True, как и ожидалось.

Это будет медленнее, поскольку вы создаете лишний пустой список без необходимости.

это менее читабельно, чем if not a:, и легче ломается. Пожалуйста, не делай этого.

Ранее было высказано хорошее мнение, что () == [] также равен false. Хотя мне нравится, как эта реализация читает, if not a: охватывает все случаи, если вы определенно ожидаете список, вашего примера должно быть достаточно.

нужна цитата "легче ломается"? if not a прерывается, когда a является None - вы можете желание такое же поведение для None и [], но если вы явно хотите проверить пустой список, if not a этого не сделает.

Второй способ кажется лучше, если вы хотите сигнализировать, что seq, как ожидается, будет своего рода списковым объектом.

@BallpointBen, который, как сказали бы сторонники питонизма, должен быть неявным в способе наименования переменной, насколько это возможно.

@BallpointBen попробуйте использовать Python подсказка типа для сигнализации, какой должна быть переменная. Он был представлен в версии 3.5.

numpy нарушил эту идиому ... seq = numpy.array ([1,2,3]), за которым следует if not seq, вызывает исключение "ValueError: истинное значение массива с более чем одним элементом неоднозначно. Используйте a.any () или a.all () "

Несмотря на всех сторонников Pythonic, я поддерживаю @BallpointBen в том, что если вы по ошибке написали seq = [0] как seq = 0, len(seq) поможет вам отловить ошибку. Человеку свойственно ошибаться. Так что программист.

Я только что получил это сообщение при использовании Python 3.6.4: «FutureWarning: поведение этого метода изменится в будущих версиях. Вместо этого используйте специальный тест 'len (elem)' или 'elem is not None'». поэтому я предполагаю, что это четко определяет предпочтение

@jeronimo: Я считаю, что это предупреждение, относящееся к lxml.

@aafulei Загрязнение исходного кода сигналами, помогающими программисту избежать ошибок кодирования, - глупое занятие. Неэлегантное наложение этой неуместной проблемы на исходный код приводит к тому, что код становится труднее читать и следовать, что в течение срока службы кода приводит к появлению большего, а не меньшего количества ошибок. Существуют тесты для решения проблемы (постоянного) обеспечения правильности и для отделения этой проблемы от любых других. Я новичок в Python, кстати, в этих утверждениях нет ничего Pythonic, они отражают основные принципы SRP, которые могут и должны быть выражены на любом данном языке.

@ Mr.WorshipMe, это здорово, что вы поднимаете эту тему с numpy arrays, но мы не говорим здесь о <class 'numpy.ndarray'>, мы говорим о <class 'list'>, хотя оба являются итерациями и в основном массивами, но это не главное.

Проверка того, равна ли длина списка нулю, а не просто проверка того, является ли список ложным, уродлива и непифонична. Любой, кто знаком с Python, не подумает, что li - это булево, и ему все равно. Если это важно, вы должны добавить комментарий, а не код.

Это похоже на излишне точный тест, который часто медленнее и всегда менее читабелен, ИМХО. Вместо того, чтобы проверять размер чего-то пустого, почему бы просто не проверить, пусто ли оно?

В любом случае, причина, по которой это плохо (и что нарушение идиом на языке с сильными идиомами, такими как Python, в целом плохо), заключается в том, что он сигнализирует читателю, что вы специально проверяете длину по какой-то причине (например, потому что вам нужен None или 0, чтобы вызвать исключение вместо передачи). Итак, когда вы делаете это без причины, это вводит в заблуждение - и это также означает, что, когда вашему коду делает необходимо проводить различие, различие невидимо, потому что вы «кричите волк» во всем остальном источнике.

Я считаю, что это просто ненужное удлинение кода. В противном случае, почему бы не быть еще более «явным» с if bool(len(li) == 0) is True:?

@Jabba во многих случаях это будет О (1) (те, где вы работаете со встроенными типами данных), но вы просто не можете полагаться на это. Возможно, вы работаете с настраиваемым типом данных, у которого нет этого свойства. Вы также можете решить добавить этот настраиваемый тип данных позже, после того, как вы уже написали этот код.

Очень плохо хвататься за длину только для проверки на пустоту. Это никуда не годится.

Это анти PEP 8

Что, если вы делать хотите вызвать исключение для типов без __len__? В таком случае это идеально.

Если неясно, что li - это список, возможно, вам не стоило называть его li. Я думаю, что очень мало хороших имен переменных, состоящих всего из двух букв. А как насчет cars или evasive_manoeuvres? С другой стороны, логические значения должны содержать в имени is или has или другой глагол, сравните if is_evasive_manoeuvre: и if evasive_maoeuvres. Мне ясно, что является bool, а какое - коллекцией.

Это как показать другу контейнер, полный 0 апельсинов. Это не контейнер с апельсинами ... и если он не имеет ничего общего с contain ... тогда это вообще можно было бы утверждать, что это контейнер. Он становится контейнером, содержащим содержимое, только после того, как содержимое содержится. (x_x)

По крайней мере, он не скажет, что a пуст для a == None, в то время как not a будет оцениваться как True для a == None.

На мой взгляд, not X решает проблему True для слишком многих возможных случаев X. В частности, пустой список и None. Хотя случай, когда значением является либо пустой список, либо None, вероятно, не произойдет должен, я не уверен, что это буду не произойдет. Особенно, когда другие люди используют части моего кода. Несмотря на то, что это анти-PEP 8, я все же предпочитаю этот подход.

@augurar: Обращаясь к идее, что это просто делает его излишне более явным, стоит отметить, что if bool(len(li) == 0) is True делает то же самое, что и if len(li) == 0, и поэтому нет смысла добавлять этот дополнительный код. Однако if len(li) == 0 определенно делает нечто иное, чем if li. Я думаю, что разумно утверждать, что люди не должны кодировать вещи таким образом, чтобы последнее сравнение давало разные результаты. Однако последнее сравнение может дает другие результаты, тогда как первое сравнение не можешь, поэтому я не думаю, что это хороший аргумент.

@ShianiaWhite неверно, это ужасный способ проверить, является ли len в списке пустым или нет. Нет необходимости вычислять len последовательности, чтобы проверить ее пустоту, у python уже есть наши спины, он легко дает значение истинности последовательности ... так что выполнение if l - в значительной степени лучшее. Представьте себе последовательность размером почти миллион, не хотели бы мы тратить наши жизни, чтобы получить len? Ответ Патрика - лучший.

@StackOffended Временная сложность len в списке - O (1), а не O (n), как вы могли подумать. См. здесь для получения дополнительной информации.

о, это здорово! это поддерживает ваш аргумент, но я думаю, что после 8 лет этой темы выполнение if a по-прежнему будет рекомендовано & pythonic.

@IceBear Используйте то, что хотите. Спустя 8 лет я все еще предпочитаю len(a).

Вау, это потрясающе! Я понимаю, что временная сложность len(a) в качестве примера - O(1). Но для меня я просто считаю, что это pythonic и еще что-то вроде logical для использования if a. Я все еще поражаюсь после того, как 8 слышал, что вы все еще предпочитаете это: D haha

Как разработчику, пришедшему с C / C++, это особенно вредит моему мозгу, и сначала я нашел первый комментарий в этой ветке абсурдным. "Проверка, не является ли список ложным" ??? Что все это значит. Как это вообще понятно программисту? Я ожидал, что что-то вроде not None вернет True - в этом есть смысл. Но объект списка? У него есть тип! Это не пустяк. Это просто свойство Python, что (почти) все встроенные типы предлагают приятную логическую оценку, которая имеет смысл в контексте типа и которую нужно уважать, чтобы быть успешным Pythonista.

Стоит отметить, что это не недостаток Python, а, скорее, преднамеренный разрыв контракта со стороны numpy - numpy - это библиотека с очень конкретным вариантом использования, и у нее есть другое `` естественное '' определение того, что такое истинность в массиве. стандарту Python для контейнеров. Имеет смысл оптимизировать для этого случая, так как pathlib использует / для объединения путей вместо + - это нестандартно, но имеет смысл в контексте.

Согласовано. Я хочу сказать, что важно помнить, что numpy сделал выбор, чтобы сломать утиную типизацию как для очень распространенных идиом if x, так и для len(x), и иногда эту поломку очень трудно обнаружить и отладить.

Я не знаю, для меня, если метод с именем len (x) не возвращает длину массива из-за предположений, его имя плохо спроектировано.

@Dalton Я не согласен с этой интерпретацией len() для массивов numpy. Если вы конвертируете numpy.zeros((1,0)) в список, вы получите [[]], что является логическим значением true. Массив numpy не пуст, потому что он содержит один (пустой) массив.

@pydsigner Я согласен с вашим выводом, но я буду спорить с вашей логикой, особенно с вашим последним предложением. numpy.zeros((1,0)) определенно не является массивом, содержащим один (пустой) массив; это просто единственный массив, не содержащий элементов. Массивы Numpy не вложены. Когда вы запускаете tolist, вы получаете список, содержащий один (пустой) список, но это совсем другой зверь. С другой стороны, кажется, что len просто дает размер первого измерения массива. Это не неправильный; это просто выбор (хотя я бы его не сделал).

@Mike В то время как str () массива 1x0 - [], запуск for sub in numpy.zeros((1,0)): print sub будет выводить [] как внутренний массив, а не ничего не печатать. Причуда представления массива не должна определять, как мы рассматриваем конструкцию.

Я не уверен, что понимаю вашу точку зрения. Если вы используете print(type(sub)) в своем примере, вы получите <class 'numpy.ndarray'>, а не list. Во всяком случае, это не имеет значения, потому что это просто означает, что они реализовали итерацию. В этом нет никакой причуды: от их интерфейса на уровне Python до реализации C API, вплоть до их размещения в памяти, массивы numpy являются многомерными массивами, а не вложенными массивами или списками. Вы можете разрезать их для извлечения подмассивов, но это не имеет ничего общего с вложенностью.

Этот вопрос не имеет ничего общего с массивами numpy

@ppperry Да, исходный вопрос не касался массивов Numpy, но при работе с этими и, возможно, типизированными аргументами этот вопрос становится очень актуальным.

Способ нимпифонический на случай, если вы также хотите заставить свой код работать, если указан список, - это сначала принудительно ввести любой возможный ввод в массив numpy с помощью asarray. После этого вы можете продолжить, как в своем ответе, не беспокоясь о других форматах.

@BasSwinckels Хорошее замечание. Я предполагаю, что не всегда стоит прилагать усилия, если задача Только, которую вы хотите сделать, - это проверить, пуст ли ввод, но, безусловно, это то, что мы обычно делаем, когда действительно хотим что-то сделать с вводом. Я добавлю это к своему ответу. Спасибо.

«len (numpy.zeros ((1,0))) возвращает 1, даже если в массиве ноль элементов». Это IMO не сильно отличается от списка, содержащего пустой список. оба имеют len 1 и приводят к одной итерации, когда вы их перебираете.

@plugwash Об этом говорилось выше, поэтому я просто повторю, что все остальное о numpy - от кода C до других аспектов его высокоуровневого интерфейса - говорит о том, что массив определенно является нет вложенным типом объекта; это единый многомерный объект. То есть numpy.zeros((1,0)) не должен рассматриваться как массив, содержащий другой массив (который просто оказывается пустым). Вместо этого его следует рассматривать как единый двумерный массив, не содержащий элементов. И в результате вам нужно помнить о различии всякий раз, когда вы проверяете пустой массив.

@GarethLatty: совсем нет. / может применяться только между Path и str или объектами, подобными пути. И это питонический очень, поскольку Python - язык со строгой типизацией. Кроме того, + кажется скорее конкатенацией между строками, и это нет поведение объединения путей (попробуйте, например, Path("a") / "b/"). Наконец, много более элегантен для соединения путей с /. Напротив, numpy реализовал операторы между кошками и собаками. Таким образом, они полностью нарушили любой контракт Python.

@GarethLatty: например, если я хочу создать функцию, которая может принимать любую итерацию, и мне нужно использовать bool() или len(), я вынужден проверять, является ли итерация ndarray, и угрожать ей другим способом. Так куда делась утиная машинка? Утку съел numpy, жаждущий привлечь пользователей Matlab :-D

Если len(zeros((1,0)) вернул 0, то len(zeros((2,2)) должен вернуть 4. Для этого есть метод size. Если array.shape - это (2,3,4), то array[1].shape - это (3,4), что означает, что первое измерение работает как контейнер для конечных измерений и т. д., Точно так же, как вложенный список. Так что ожидаемый результат len(array) наверняка - array.shape[0]. А zeros((1,0)) что-то содержит: он содержит одно конечное измерение с экстентом 0.

Довольно редко у вас будет исчерпывающий список из 6 типов, которые вы хотите принять и не будете гибкими для каких-либо других типов. Когда вам нужны такие вещи, вы, вероятно, захотите азбуку. В этом случае, вероятно, это будет одна из ABC stdlib, например collections.abc.Sized или collections.abc.Sequence, но это может быть та, которую вы пишете сами и на которой register(list). Если у вас действительно есть код, в котором важно отличать пустые значения от других ложных, а также отличать списки и кортежи от любых других последовательностей, тогда это правильно, но я не верю, что у вас есть такой код.

Причина, по которой людям это не нравится, заключается в том, что в большинстве случаев это совершенно бессмысленно. Python - это язык с утиным типом, и этот уровень защитного кодирования активно этому препятствует. Идея системы типов Python заключается в том, что все должно работать до тех пор, пока объект передается в функциях так, как ему нужно. Выполняя явную проверку типов, вы заставляете вызывающую сторону использовать определенные типы, что противоречит самой сути языка. Хотя иногда такие вещи необходимы (исключение обработки строк как последовательностей), такие случаи редки и почти всегда лучше всего занести в черные списки.

Если вы действительно хотите проверить, является ли значение именно [], а не чем-то ложным другого типа, тогда, безусловно, требуется if a == []:, а не возиться с isinstance.

Тем не менее, для == есть несколько автоматических принудительных действий. Совершенно верно, я не могу определить ни одного для []. Например, [] == () возвращает False. Но, например, frozenset()==set() возвращает True. Так что стоит хотя бы немного подумать о том, может ли какой-то нежелательный тип быть приведен к [] (или наоборот) при выполнении a == [].

@RemcoGerlich - isinstance () по-прежнему предпочтительнее, чем создание пустого списка для сравнения. Кроме того, как указывал другой, оператор равенства может вызывать неявное преобразование некоторых типов, что может быть нежелательным. Нет причин когда-либо кодировать "a == []", и этот код определенно будет отмечен как дефект в любой проверке кода, в которой я участвовал. Использование соответствующего инструмента, предоставляемого языком, не должно рассматриваться как "заблуждение о , "а скорее" хорошая техника программирования ".

Вместо того, чтобы вручную проверять типы, вы должны использовать подсказка типа (введено в 3.5).

Подсказки @Boris Type помогают средствам проверки статического типа (например, mypy) проверять правильность типа, но не выполняют проверку типа во время выполнения.

«И когда вы нарушаете эти идиомы, это сильный сигнал». Это может быть сильным сигналом того, что вы просто работаете с кодом, написанным кем-то, кто плохо знаком с python, а это много людей.

Дело в том, что проверить, пуст ли список, очень важно, по крайней мере, для меня. Задумывались ли вы, есть ли внутри <rest of code> какой-нибудь скрипт, который может использовать результат цикла for? Или напрямую использовать какие-то значения в a? Действительно, если сценарий предназначен для запуска со строго контролируемым вводом, проверка может быть немного ненужной. Но в большинстве случаев входные данные меняются, и обычно лучше иметь чек.

С уважением, нет. Я считал, что кто-то недостаточно разбирается в Python, чтобы знать, что «if <list>:» - правильный ответ, спрашивает, как проверить наличие пустого списка. Затем я замечаю МНОГО ответов, в которых высказывались разные мнения, но ни один из них, похоже, не отвечал первоначальной потребности. Вот что я попытался сделать со своим ответом - попросить их изучить потребность, прежде чем продолжить. Я полагаю, что прямо высказал это в своем ответе.

@ AmarthGûl - Как можно получать обработать результаты из цикла for скрипту внутри <остальной части кода>? Может быть, в списке? А может дикт? Если да, то применима та же логика. Я не понимаю, как ввод переменных может иметь какой-либо эффект в любом виде разумно спроектированного кода, где обработка пустого списка была бы плохой идеей.

Немного устарел, но если бы вы просто проверяли, был ли список пустым, для непустого списка ваш код повторяет процесс снова и снова, когда OP просто ищет операцию проверки. Только представьте себе худший сценарий для этого кода, когда n приближается к бесконечности ....

@DJK Я считаю, что вы, возможно, упустили суть, но для пустого списка код проваливается. Для непустого списка вы просто обрабатываете каждый элемент по мере необходимости. Дело было в том, что «в большинстве случаев проверка на пустоту не требуется». Это вдвойне так, потому что OP не знал, что «if a_list:» был правильным ответом, поэтому потенциально был начинающим разработчиком Python.

Нет, вы создали ошибку O (n) по чеку. вы только рассматриваете хороший результат в пустом списке. Ответ работает, но, на мой взгляд, он неоптимален.

@DJK - Нет, я думаю, тебе все еще не хватает этого. Предположительно, вы хотите что-то сделать со списком, если он у вас есть. Что бы вы сделали иначе, если бы он был пуст? Вернуться раньше? Что делать, если он не пустой? обработать это? Дело в том, что вам не нужно проверять наверное на пустой список, просто перебирайте его и делай то, что собирался делать с элементами. Если нет элементов, вы проваливаетесь. Если есть элементы, вы их обрабатываете как нужно. Дело НЕ в том, чтобы использовать пример для пустой проверки, а в том, чтобы НЕ проверять вообще, просто обработайте список.

@DJ_Stuffy_K утверждать, что в модульном тестировании пустой список? Просто используйте assert(not myList). Если вы также хотите утверждать, что объект является list, вы можете использовать assertIsInstance().

ИМХО, это лучший ответ. Учитываются нюансы применительно к None и [] (пустой список) при тестировании.

Для тех (вроде меня), кто не знал, bool() преобразует переменную Python в логическое значение, поэтому вы можете хранить правду или ложь значения без использования оператора if. Я думаю, что это менее читабельно, чем просто использовать условное выражение, такое как принятый ответ, но я уверен, что для него есть и другие хорошие варианты использования.

Это можно использовать в выражениях и является более кратким.

Обратной стороной является a is None. Часто это приемлемо, но стоит знать об этом.

Overbroad; это просто вопрос, пуст ли список, а не является ли что-то пустым итерабельным.

Если меня не устраивает if a:, то это потому, что мне нужно исключение, если a не является чем-то вроде контейнера. (Наличие повторяемый также позволяет использовать итераторы, которые бесполезно тестировать на пустоту.)

Я хотел бы отметить, что это также верно для непустого корпуса, хотя он довольно уродлив, как с l=[], затем %timeit len(l) != 0 90,6 нс ± 8,3 нс, %timeit l != [] 55,6 нс ± 3,09, %timeit not not l 38,5 нс ± 0,372. Но никому не понравится not not l, несмотря на тройную скорость. Это выглядит смешно. Но скорость побеждает

Я полагаю, проблема заключается в тестировании с помощью timeit, поскольку достаточно только if l:, но на удивление %timeit bool(l) дает 101 нс ± 2,64 нс. Интересно, что без этого штрафа невозможно принудительно использовать bool. %timeit l бесполезен, так как преобразование не произойдет.

Лучший ответ на данный момент, спасибо! Указание на истинную логику Python с помощью магических методов и «Python написан на C; он использует свою логику на уровне C. Все, что вы напишете на Python, будет медленнее. И это, вероятно, будет на несколько порядков медленнее» является ключевым моментом. иначе человек попадает в «предпочтения» и никогда не приходит к правильному выводу.

Большой! Это лучший ответ! Всем, кто читает с 2020 года (это декабрь, значит, уже почти 2021 год) и в будущем. Выполнение if l - это "питонический" способ и ЛУЧШИЙ способ, так как этот парень очень хорошо это объясняет, а также предоставил некоторый образец кода временной производительности, рассчитанной для каждого предлагаемого ответа, а именно if len(a) == 0, if [] == [] и if a. Итак, ясно, что это (if a) намного быстрее и тот, который нужно практиковать!

Название is_empty предполагает, что он что-то возвращает. Но если бы это было так, то это был бы просто bool(any_structure), который вы должны использовать вместо него (когда вам вообще нужен bool).

Зачем нам нужен вариант bool, который (также) выводит сообщения на стандартный вывод?

@DavisHerring У нас всегда есть два варианта: сначала напечатать с помощью функции, а другой - с помощью возвращаемой переменной bool. Твой выбор. Я пишу оба, чтобы вы могли выбирать между ними.

all (bool (x) for x in l) истинно для пустого списка

Возможно, это вызовет исключение, если a не является списком, а a не имеет реализованного метода __len__. Я бы порекомендовал: if isinstance(obj, list): if len(obj) == 0: print '...'

@ SvenKrüger нет. Оператор and в Python ленив. Ничто после and не будет выполняться, если условие перед and имеет значение False.

пожалуйста, дайте больше объяснений о том, как это работает, не написав «если»?

Это не питонический и не полный пример. Кроме того, он создает пустой список каждый раз, когда он встречается. Не делай этого.

@MrWonderful он не создает каждый раз пустой список. Он просто проверяет, пуст ли существующий список a.

@MrWonderful Я не понимаю, что делает его pythonic

@ganeshdeshmukh, если вы используете a==[], он будет печатать true на терминале python, если a пуст. В противном случае он напечатает False. Вы можете использовать это внутри условия if также как if (a==[])

Проголосовали за то, что также показали, как проверить, не пусто ли оно! Это помогает охватить противоположный, но не менее важный вариант использования.

Обратите внимание, что второй может не работать с другими объектами распространенного типа массива, такими как массивы numpy.

-1 - Чтобы избежать путаницы, не используйте зарезервированные слова для имен переменных, иначе вы можете получить неожиданное поведение в следующий раз, когда попытаетесь вызвать, например, "list ()" ... что-то вроде "TypeError: 'list' object is не вызывается "или что-то в этом роде.