Разница между collections.abc.Sequence и typing.Sequence

На самом деле, в вашем коде вам не нужен ни один из них:

Ввод с аннотациями, который вы делаете с импортированным классом Sequences, является дополнительной функцией, предназначенной для (1) быстрой документации; (2) проверка кода перед его запуском с помощью статических анализаторов кода, таких как Mypy.

Дело в том, что некоторые IDE по умолчанию используют результат статической проверки в своих рекомендуемых конфигурациях, и могут сделать так, что код без аннотаций "неисправен": это не так - это необязательная возможность.

Пока объект, который вы передаете в свою функцию, учитывает часть интерфейса Sequence, который ему понадобится, он будет работать (ему нужны __len__ и __getitem__ как есть)

Просто запустите свой код без аннотаций и посмотрите, как он работает:

def average(myvariable):
    return sum(myvariable) / len(myvariable)

Тем не менее, вот что происходит: list — это превосходная «последовательность» в Python, которая реализует все, что нужно последовательности.

typing.Sequence — это просто индикатор для инструментов статической проверки, что данные, помеченные им, должны соответствовать протоколу Sequence и ничего не делают во время выполнения. Вы не можете создать его экземпляр. Вы можете наследовать от него (вероятно), но только для того, чтобы специализировать другие маркеры для набора текста, а не для чего-либо, что будет иметь какой-либо эффект во время фактического выполнения программы.

С другой стороны, collections.abc.Sequence предшествует необязательным рекомендациям по вводу в PEP 484: он работает как «виртуальный суперкласс», который может указывать все, что работает как последовательность во время выполнения (с помощью isinstance) (*). И его можно использовать в качестве надежного базового класса для реализации собственных полнофункциональных классов cusotm Sequence: просто наследуйте от collections.abc.Sequence и реализуйте функциональные методы __getitem__ и __len__, как указано в документации здесь: https://docs.python.org /3/library/collections.abc.html (то есть для последовательностей только для чтения — для изменяемых последовательностей отметьте collections.abc.MutableSequence, конечно).

(*) чтобы ваша пользовательская реализация последовательности была распознана как собственно последовательность, она должна быть «зарегистрирована» во время выполнения с вызовом collections.abc.Sequence.register. Однако, насколько мне известно, большинство инструментов для статической проверки типов не распознают это и будут ошибаться в своем статическом анализе)

Хорошо, что вы используете аннотации типов! Как говорится в документации, если вы используете Python 3.9+, вам, скорее всего, никогда не следует использовать typing.Sequence из-за его устаревания. С момента введения универсальных типов псевдонимов в 3.9 классы collections.abc все поддерживают подписку и должны правильно распознаваться средствами проверки статических типов всех разновидностей.

Таким образом, преимущество использования collections.abc.T вместо typing.T в основном заключается в том, что последний устарел и не должен использоваться.

Как упомянул jsbueno в своем ответе, аннотации никогда не будут иметь последствий во время выполнения, если, конечно, они не будут явно выбраны фрагментом кода. Они просто неотъемлемая часть хорошего стиля кодирования. Но ваша функция все равно будет работать, то есть ваш скрипт будет выполняться без ошибок, даже если вы аннотируете свою функцию чем-то абсурдным, например def average(sequence: 4%3): ....

Правильные аннотации по-прежнему чрезвычайно ценны. Таким образом, я бы порекомендовал вам как можно скорее привыкнуть к некоторым из лучших практик. (Более или менее строгая проверка статического типа, такая как mypy, очень полезна для этого.) Во-первых, когда вы используете универсальные типы, такие как Sequence, вы всегда должны предоставлять соответствующие аргументы типа. Это могут быть переменные типа, если ваша функция также является универсальной, или они могут быть конкретными типами, но вы всегда должны их включать.

В вашем случае, если вы ожидаете, что содержимое вашего sequence будет чем-то, что можно добавить с тем же типом и разделить на целое число, вы можете, например, захотеть. обозначьте это как Sequence[float]. (В системе типов Python float считается супертипом int, хотя номинального наследования нет.)

Еще одна рекомендация — постараться использовать как можно более широкие типы параметров. (Это перекликается с парадигмой динамической типизации Python.) Идея состоит в том, что вы просто указываете, что ожидаемый объект должен уметь «крякать», но не говорите, что он должен быть уткой.

В вашем примере, поскольку вы полагаетесь на совместимость аргумента с sum , а также с len , вам следует подумать, какие типы ожидают эти функции. Функция len проста, так как она просто вызывает метод __len__ объекта, который вы ей передаете. Функция sum более тонкая, но в вашем случае важная часть заключается в том, что она ожидает итерируемого элементов, которые можно добавить (например, float).

Если вы посмотрите на Азбуку коллекций, вы заметите, что Sequence на самом деле предлагает гораздо больше, чем вам нужно, поскольку это обратимая коллекция. Collection — это самый широкий встроенный тип, который соответствует вашим требованиям, потому что он имеет __iter__ (из Iterable) и __len__ (из Sized). Итак, вы могли бы сделать это вместо этого:

from collections.abc import Collection


def average(numbers: Collection[float]) -> float:
    return sum(numbers) / len(numbers)

(Кстати, имя параметра не должно отражать его тип.)

Наконец, если вы хотите сделать все возможное и быть максимально широким, вы можете определить свой собственный протокол , который даже шире, чем Collection (путем избавления от наследования Container):

from collections.abc import Iterable, Sized
from typing import Protocol, TypeVar


T = TypeVar("T", covariant=True)


class SizedIterable(Sized, Iterable[T], Protocol[T]):
    ...


def average(numbers: SizedIterable[float]) -> float:
    return sum(numbers) / len(numbers)

Это имеет то преимущество, что поддерживает очень широкое структурное подтипирование, но, скорее всего, это излишне.

(Чтобы ознакомиться с основами типизации Python, обязательно прочтите PEP 483 и PEP 484.)