Речь не о лучше или хуже
Лучше отсутствием необходимости писать реализацию __iter__ и самого итератора вручную. Ну а __next__ уже в автоматически созданном итераторе сам будет.
next и iter это про итератор,а не про итерейбл
Получается, бывает итерейбл без итератора...?
Итерейбл это наличие __iter__
Iterable — значит от объекта можно получить итератор.
Во, спасибо, полегчало. То есть, объект с getitem - он iterable, потому как возвращает "старый" вариант итератора?
Ну типа да, но наличие __getitem__ порождает вызов "неявного" __iter__ и это тоже сойдёт за итерабль.
Мне не нравится такое поведение.
Пуркуа бы и не па.
А еще можно "заменить" __contains__ на __getitem__
Ну, не "старый вариант итератора", просто он неявно получается. Итератор вполне обычный.
Да и на __iter__ можно. :-)
Клёво! Всё, спасибо. Понял. Да, явное лучше, чем неявное. Ещё вопрос: Хочу свои iterable object. Не знаю, дом с жильцами, колода карт, сотрудники магазина. Я всё это делал на основе списков, туплов, генераторов и т.д. То есть, на основе имеющегося. Это оно так и делается? Или надо в более низкоуровневые дебри вдаваться?
как удобнее, так и делай. Можно вообще в __iter__ написать return iter(self.my_list) и готово :D
It depends. Если итерабля представляет собой объект в памяти, вероятно есть смысл строить её поверх встроеннй структуры. Банально потому что 1) они побыстрее работают, потому что на сях и 2) выбор особо не велик. Но если отвлечься от того, что явным образом напоминает последовательность, например какое-нибудь дерево, которое надо обходить — и у нас появляется уже не одна структура, а несколько, а если мы последовательно скачиваем какие-нибудь файлы, причём динамически, то там в итераторе уже и всякие http-запросы появятся.
А то я порываюсь свой "список" с нуля создать
Принято, спасибо. Не, у меня пока проще, без деревьев и запросов)
А в питон уже добавили async for?
Внезапность вопроса ставит меня в тупик. :-)
А f-строки уже пробовал? Прикольная фича.
Обсуждают сегодня