Пишем на Питоне сразу хорошо

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

В том то и дело, что это очень НЕ просто. Часто это — небо и земля. Трудоемкость обработки миллионов и миллиардов элементов вместо десятков-сотен-тысяч может быть в тысячи раз затратнее и по деньгам, и по времени, и по ресурсам.
Понадобятся другие (обычно более сложные) алгоритмы, библиотеки и часто нетривиальные и возможно компромиссные решения.

setattr(self, f'value_{v}', 1)

ломает рефакторинги с полями `self.value_...` и полнотекстовый поиск по имени поля. Не надо такому учить.

В разделе Dangerous loops вам вообще не нужно условие, его надо было перенести в while…

Половина советов — очень спорно. Выше уже много заметили.
Я бы добавил, что:

if v == 'a':
    self.value_a = 1
elif v == 'b':
    self.value_b = 1
elif v == 'c':
    self.value_c = 1

Лучше переписать с применением словаря.
Использование setattr — крайне опасно, и его стоит по возможности всегда обходить стороной. Типы не проверяются, при рефакторинге оно не найдётся.

привет, kesn. Читал статью и кивал: вроде бы и да, а вроде бы и нет.

Писать на Python можно сразу хорошо, только у всех это свое хорошо. Тут соглашусь с David Beazley, что большинство не понимает идеологию Python вообще, но это не мешает им создавать интересные решения.

Что мне кажется полезным использовать:

1. Генераторы и Pipe-generators в любом виде.
Все, что необходимо для перечисления в последующих функциях, должно быть генератором.
Когда я вижу, что вычисляется лист/кортеж который прокидывается дальше в какой-нибудь цикл, то это означает, что алгоритм выполняет несколько ненужных проходов по коллекции элементов, прежде, чем выполнить что-то полезное. В моем теперешнем проекте можно встретить list только в одном случае: я пропустил это при рефакторинге.

2. Рефакторинг For цикла без использования Break.
Если идет цикл по набору элементов, который прерывается (break) по каким-либо причинам, оставляя часть элементов не обработанными, то получается, что набор был излишен. Ресурсы на создание и хранение этого набора частично были потрачены зря. Если же набор элементов — это генератор, не ясно, что мешало создать генератор на меньшее количество элементов?

3. Рефакторинг For цикла без использования Continue.
Если идет цикл по набору элементов, некоторые из которых пропускаются (continue) по каким-либо причинам, оставляя часть элементов не обработанными, то получается, что набор был излишен. Ресурсы на создание и хранение этого набора частично были потрачены зря. Если же набор элементов — это тоже генератор, не ясно, что мешало создать сразу правильный генератор?

4. While c break/continue является продолжением предыдущих выводов. Многие захотят поспорить, и я соглашусь, например, с тем, что использование break/continue убыстряет разработку, а это плюс!

5. map/zip в современном Python бессмысленны:
про map уже даже Гвидо сказал, что

«want to remove map»

zip стал не нужен после появления yield from:

zip = yield from (next(iterator) for iterator in tuple(iter(iterable) for iterable in iterables))

6. Ранний return — не панацея от удержания кода в голове. Если код надо запоминать — это скорее всего признак необходимости рефакторинга. А вот множественные точки выхода — это попо-боль для отладки.
Пример: поставил точку останова. А оно не остановилось… Оказалось создатель кода решил выйти из функции раньше.

7. Даже в документации Django list(queryset) отмечен, как опасный. Потому, как list запускает получение всех данных queryset.
Предлагаю Автору сделать assert list(queryset) на queryset под миллион записей и удивиться.
Кто-то посоветовал queryset.get(), но для версий django <=3.0 get имеет ту же проблему, я описывал это в своей статье.
Ложки Хорошего решения тут нет.
Иногда поможет queryset.exists(), но это n+1 запрос.
Иногда поможет выполнение кода и assert после:

item = None
for item in Item.objects.all()[:1]:  #  для твоего кода 
    print (item)
assert item  # для любителей assert-ов

8. select_related / prefetch_related ТОЛЬКО в случаях, когда это действительно надо.
Такое надо в коде бывает редко, если алгоритм выполняет то, что должен, и не более.
Пример: В Django 1.4 я прилепил select/prefetch всего сразу на базовый queryset цены товаров в магазине. Спустя 4 года любое обращение к queryset цен стало вешать базу. Я начал плакать, кода посмотрел код sql запроса price.objects.count(), который вызывается дважды в AdminModel в шаблоне change_list.html

В итоге Автор напомнил мне меня же лет 6 назад. Я тогда уже наелся первой стрельбой по ногам от python/django и сформировал кодекс «пиши вот так...». Cпустя время каждое второе правило этого кодекса оказалось очередной «случайной пулей в ногу», ведь задачи стали совершенно другими.

Автору успехов

Полезно
С assert всё неоднозначно. В django решили заменить большинство assert(не все) на генерирование исключения. В то же время в DRF решили не следовать данному примеру. Моё мнение — наличие опции "-O" у интерпретатора python как бы говорит о том что разработчики языка не планировали что assert будет использоваться для валидации.

result = get(service_url).json()
assert result in {'ok', 'fine', 'good'}

это прям идеальный пример неправильного использования assert — внешние данные им проверять точно не стоит.