10 итераторов, о которых вы могли не знать

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

10 итераторов, о которых вы могли не знать

Рад, что статья понравилась, буду думать, как придумывать названия лучше)

10 итераторов, о которых вы могли не знать

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

10 итераторов, о которых вы могли не знать

Просто эта статья про Python, я не старался сравнивать с другими языками, а старался показать возможности Python при работе с итераторами и коллекциями. Конечно, и в других языках есть похожие инструменты

10 итераторов, о которых вы могли не знать

Есть ещё вот такой способ:

from itertools import islice

a = [1, 2, 3, 4, 5, 6]
iterator = iter(a)
list(iter(lambda: list(islice(iterator, 3)), []))
# [[1, 2, 3], [4, 5, 6]]

10 итераторов, о которых вы могли не знать

Никогда не использовал, но, да, идея с parametrize и product очень интересная

Алгебраические типы данных и Python

Это как раз вариант с иерархией классов. Часто тип-сумма (тип Union в Python) является более простой альтернативой. Представьте, например, что нужен не только метод sign_in, а метод log для логирования, и метод save_to_db для сохранения в базу данных. Получится, что абстрактный класс должен определять, а все конкретные классы должны реализовывать и эти новые методы. А если таких методов будет не 3, а 10? Каждый класс в иерархии должен знать как обрабатывать sign_in, как логировать какую-то информацию о себе log, как сохранить в БД save_to_db, и т.п. Скорее всего, понадобится использовать паттерн Visitor, чтобы как-то разделить ответственности, определять новый интерфейс visitor-а и реализации.

Алгебраические типы данных и Python

Спасибо за развернутый ответ, интересно

Алгебраические типы данных и Python

А что значит?

Вообще он показывает любое отрицание.

Алгебраические типы данных и Python

Спасибо, да, согласен с комментариями выше, часто приходится работать с уже довольно большой кодовой базой, в которой нет аннотаций типов вообще. Но есть возможность файл за файлом, постепенно добавлять аннотации типов и mypy будет их проверять. Это как раз и называется gradual typing, и в этом его главная ценность. Понятно, что если вы пишете какой-то простой скрипт автоматизации, или, например, исследуете данные в Jupyter Notebook, то вам не нужны никакие аннотации. И, конечно, вы можете их не использовать. Но если вы разрабатываете большое приложение, то ценность аннотаций и статических проверок значительно увеличивается. Вот, например, история, как dropbox добавлял аннотации для 4 млн строк кода:
dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python

Алгебраические типы данных и Python

Спасибо, да, согласен, с Haskell на этом поле сложно конкурировать. Не только Python, но и любому другому языку

Алгебраические типы данных и Python

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

Алгебраические типы данных и Python

Полностью согласен

Алгебраические типы данных и Python

Вы объявили тип-сумму с двумя конструкторами данных, используя синтаксис Haskell, если я правильно понимаю. Это больше похоже на простой тип-перечисление (Enum в Python). Думаю, что такой тип эквивалентен:

data Foo = Bar () | Baz ()

т.е. в некотором смысле, это композиция единичных типов.
Или я не прав?

Когда уходят на покой программисты? 35 — это конец карьеры?

Видел похожую мысль в выступлении Роберта Мартина про удвоение числа программистов каждые 5 лет:
www.youtube.com/watch?v=zHiWqnTWsn4&t=765s.
Откуда следует интересный вывод, что половина программистов в мире имеет опыт менее 5-ти лет, и это соотношение всегда соблюдалось.

Протоколы в Python: утиная типизация по-новому

Действительно, интересная тенденция в сторону статической типизации. А термин в случае Python, мне кажется, оправдан. Авторы PEP-а прямо говорят, что выбрали protocol, так как этот термин уже широко используется в Python, и введение нового термина (например, интерфейс или что-нибудь такое) создало бы больше путаницы.
www.python.org/dev/peps/pep-0544/#id23

Протоколы в Python: утиная типизация по-новому

Термин протокол уже довольно давно используется в Python: протокол итераций, протокол дескрипторов, протокол контекстных менеджеров, и т.п. Так что это не совсем новый термин для Python. В других языках, конечно, есть похожие концепции: интерфейсы, трейты, концепты, протоколы, и т.д. Опять же, если искать аналогии в других языках, то мне кажется интерфейсы в Go / TypeScript больше всего похожи на протоколы в Python.

Протоколы в Python: утиная типизация по-новому

Duck может переопределить методы своего базового класса Bird, главное чтобы соблюдался принцип LSP, mypy тоже может это статически проверить:
mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides

Протоколы в Python: утиная типизация по-новому

Да, протоколы напоминают интерфейсы, но не требуют явной декларации `A implements B`, которая необходима в Java, если я правильно понимаю. В этом смысле они больше похоже на интерфейсы из Go. Так же протоколы могут объявлять не только необходимые методы, но и атрибуты (поля, свойства).

Протоколы — это обычные классы в Python, и один протокол может являться наследником другого. Например (раздел из PEP):

from typing import Iterable, Hashable

class HashableFloats(Iterable[float], Hashable, Protocol):
    pass

def cached_func(args: HashableFloats) -> float:
    ...
cached_func((1, 2, 3)) # OK, tuple is both hashable and iterable

В вашем примере Klass будет соответствовать протоколу AB.

Не совсем понял про список протоколов в типе аргумента.