Comments 9
Мне кажется, стоит посмотреть на концепцию интерфейсов в Java, например. Эти протоколы очень их напоминают.
Допустим, есть класс Klass, который реализует "протоколы" A, B и С.
Если я хочу чтобы моя функция принимала объекты протоколов A и B мне придется объявить новый протокол AB? Будет ли объект класса Klass ему соответствовать?
Может быть было бы удобнее указывать список протоколов в типе аргумента?
Да, протоколы напоминают интерфейсы, но не требуют явной декларации `A implements B`, которая необходима в Java, если я правильно понимаю. В этом смысле они больше похоже на интерфейсы из Go. Так же протоколы могут объявлять не только необходимые методы, но и атрибуты (поля, свойства).
Протоколы — это обычные классы в Python, и один протокол может являться наследником другого. Например (раздел из PEP):
В вашем примере Klass будет соответствовать протоколу AB.
Не совсем понял про список протоколов в типе аргумента.
Протоколы — это обычные классы в 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.
Не совсем понял про список протоколов в типе аргумента.
Я бы скорее обратился к интерфейсам как они определены у Банды Четырех. Протоколы как раз им полностью соответствуют.
«Если класс Duck явно объявлен наследником класса Bird, то объекты класса Duck могут быть использованы везде, где ожидаются объекты класса Bird.»
При условии, что методы Bird не переопределены (настроены) в Duck, частично или полностью.
При условии, что методы Bird не переопределены (настроены) в Duck, частично или полностью.
Duck может переопределить методы своего базового класса Bird, главное чтобы соблюдался принцип LSP, mypy тоже может это статически проверить:
mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides
mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides
Так ведь это концепты. Для чего новый термин — протокол?
Термин протокол уже довольно давно используется в Python: протокол итераций, протокол дескрипторов, протокол контекстных менеджеров, и т.п. Так что это не совсем новый термин для Python. В других языках, конечно, есть похожие концепции: интерфейсы, трейты, концепты, протоколы, и т.д. Опять же, если искать аналогии в других языках, то мне кажется интерфейсы в Go / TypeScript больше всего похожи на протоколы в Python.
Забавны два момента:
1. как всевозможные языки, изначально типизации не имевшие, дрейфуют в сторону классической статической типизации
2. и то, с каким упорством авторы различных языков придумывают новые названия для существующих паттернов. Как будто слова концепт, интерфейс и тому подобные защищены авторским правом :)
1. как всевозможные языки, изначально типизации не имевшие, дрейфуют в сторону классической статической типизации
2. и то, с каким упорством авторы различных языков придумывают новые названия для существующих паттернов. Как будто слова концепт, интерфейс и тому подобные защищены авторским правом :)
Действительно, интересная тенденция в сторону статической типизации. А термин в случае Python, мне кажется, оправдан. Авторы PEP-а прямо говорят, что выбрали protocol, так как этот термин уже широко используется в Python, и введение нового термина (например, интерфейс или что-нибудь такое) создало бы больше путаницы.
www.python.org/dev/peps/pep-0544/#id23
www.python.org/dev/peps/pep-0544/#id23
Sign up to leave a comment.
Протоколы в Python: утиная типизация по-новому