Почему вы много работаете, а зарабатываете сильно меньше чем должны?

Есть мнение, что "величайший риск — это не рисковать совсем…".
Да и как становиться сильнее без преодоления трудностей? Думаю, посыл был больше в том,что нужно работать не 12 часов, а головой.

Улучшаем свой код на Python

Спасибо, успех ни кому не помешает! =) Также благодарю за старательно написанные комментарии. Как раз подобные обсуждения и ценны.

По поводу словарей ответил ниже.

По тернарникам и условиям: именно поэтому и написал, что от него "можно уйти в некоторых случаях". Бывают ситуации, где коротенькое or смотрится гораздо лучше более громоздкого аналога. Посчитал, что начинающим кодерам не помешает знать о такой возможности.

С остальным согласен) особенно про приоритет стилистики проекта над стилистикой ревьюера.
P.S. Торжественно клянусь, что ни разу не заворачивал ревью из-за использования тернарника вместо or =)

Улучшаем свой код на Python

Я исходил из того, что если мы хотим получать именно ошибку, то можно оставить стандартное поведение словаря, либо же использовать Pydantic для валидации.

Но часто при работе с нестрогими структурами, получаемыми по API, нам хватает условности, что несуществующий == None.

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

Улучшаем свой код на Python

Верно. Хотя, кстати, с numpy тоже не все так просто. Например тот же

myarray = np.array([])
for i in range(iterations):
    myarray = np.append(myarray, i+1)

будет в разы дольше - я так и не дождался прогона)

Улучшаем свой код на Python

Интересный подход, не питонячий)

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

0.5248556137084961
0.5067837238311768
0.26512813568115234

Улучшаем свой код на Python

Именно в таком варианте не совсем будет одно и то же.

approvers = []

def check(approvers: list) -> list | bool:
    return approvers and approvers[-1].is_admin

check(approvers)  # вернет []

Лучше не мешать типы возвращаемых аргументов, так как это может привести к путанице.
Но эту конструкцию можно подправить до вида
return bool(approvers and approvers[-1].is_admin)

Улучшаем свой код на Python

Хороший коммент!

Я отталкивался от того, что используя двойной for именно в list comprehension, мы получаем плюшку в лице прироста производительности.
Вариант с product мне тоже очень понравился. Но при прочих равных предпочитаю конструкции, не требующие дополнительных импортов.

Про неочевидное поведение bool вопрос сложный. Наверное, оно само по себе протеворечит Дзену python, пункту "Явное лучше неявного".
Да, уменьшается количество кода в случаях типа sum([True, 1]) , но это действительно может обескуражить. Пожалуй, я просто уже привык к этой неявности и перестал воспринимать ее как таковую...

Улучшаем свой код на Python

МР - Merge request

По поводу "поменять местами" - можете проверить)
(Спойлер - глобально ничего не изменится. Вариант с append-ом все еще будет медленнее)

Улучшаем свой код на Python

Не соглашусь насчет прироста скорости. Многие говорят о том, что компрехи быстрее.
Да и банальные тесты показывают эту разницу.

import time
iterations = 10000000

start = time.time()
mylist = []
for i in range(iterations):
    mylist.append(i+1)
end = time.time()
print(end - start)
# 0.54514479637146

start = time.time()
mylist = [i+1 for i in range(iterations)]
end = time.time()
print(end - start)
# 0.32439470291137

Если по сравнению c filter, то да, так как она тоже быстрая. Хотя и встречал упоминания того, что компрехи весьма незначительно, но бывают быстрее. Но тут все же вопросы к читаемости лямбда-функций.

А разглядывать, что там наворочено в эту одну строчку то ещё удовольствие.
Безусловно, об этом не забыл упомянуть в статье. Если логика объемная, то генераторы списков того не стоят.

Улучшаем свой код на Python

Благодарю!)

Это оператор присваивания в выражении. Подробнее

Его используют, чтобы не здавать переменной значение отдельно. В этом же примере без него пришлось бы делать так:

user = user_dict.get("user")
if user:
  ...

# а так мы сразу и условие проверяем, и переменную заводим
if user := user_dict.get("user"):
  ...

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

Улучшаем свой код на Python

По поводу вкуса: полностью согласен. Тот же пример с sum можно и через [].count(True) решить. Но иногда бывает проще c пониманием того, что True + True == 2 . Хотел показать, что такой прием существует.

Про проверку на каждой итерации: добавил ее на случай, если мы хотим не просто молча оставить не обработанной часть результатов, а увидеть, что юзеров существует больше. В таком случае разработчик может пойти найти баг, либо ужесточить фильтры, либо элементарно увеличить max_pages

Сама проверка не ресурсозатраная, такое здорово оптимизируется, но в целом, можно обойтись и без нее

for i in range(max_pages + 1):
  ...
else:
  print("too many")

Правда, в таком варианте кода мы можем обработать на одну страницу больше, чем max_pages, затем только выкинуть, что страниц слишком много. Да и else после циклов даже для меня, любителя сахара, не прям читаем =)

Замечания полезные, благодарю!