Могут ли границы/ограничения типа храниться в глобальных переменных и позже использоваться в определениях общих функций

Могут ли границы/ограничения типа храниться в глобальных переменных и позже использоваться в определениях общих функций ⇐ Python

1 сообщение • Страница 1 из 1

Anonymous

Могут ли границы/ограничения типа храниться в глобальных переменных и позже использоваться в определениях общих функций

Цитата

Сообщение Anonymous » 31 мар 2026, 20:01

В PEP 649 в Python 3.14+ аннотации по умолчанию оцениваются лениво, и это заставило меня задаться вопросом, приемлемо ли хранить границы типов или ограничения в глобальной переменной на уровне модуля и использовать указанную переменную в определении общих функций.
Некоторые предыстории:

Я реализую тонкий уровень проверки поверх данных dict, загруженных из файла JSON (с json.load), и я подумал об определении нескольких псевдонимов типов и кортежей типов для типов данных, которые может содержать загруженный словарь, например:

Код: Выделить всё

# in types.py
type Scalar = bool | int | str |float
SCALAR_TYPES = (bool, int, str, float)

В отдельном модуле extract.py я хотел определить общую функцию для извлечения значения из словаря и проверки того, что оно является экземпляром ожидаемого типа, например:

Код: Выделить всё

def extract_scalar[T: Scalar](data: dict, key: str, expected: type[T]) -> T: ...

или даже как:

Код: Выделить всё

def extract_scalar[T: SCALAR_TYPES](data: dict, key: str, expected: type[T]) -> T: ...

Насколько я понимаю, первая подпись связывает T с любым из подтипов объединения типов Scalar, а вторая подпись ограничивает T одним из типов в кортеже SCALAR_TYPES.
Я протестировал оба подхода и убедился, что они работают с Python 3.14 как во время выполнения, так и во время статической проверки типов с помощью mypy и pyright.
Мне интересно, «разрешен» ли этот подход или полностью ли он поддерживается, и может ли он попасть в рамки лучших практик. Кажется, что это должно быть допустимо, тем более что оно предлагает более чистую альтернативу дублированию объединения типов (или кортежа) каждый раз, когда это необходимо (как, похоже, предлагает PEP 695, требуя, чтобы ограничения типа были буквальным выражением кортежа).

1774976473

Anonymous

В PEP 649 в Python 3.14+ аннотации по умолчанию оцениваются лениво, и это заставило меня задаться вопросом, приемлемо ли хранить границы типов или ограничения в глобальной переменной на уровне модуля и использовать указанную переменную в определении общих функций.
[b]Некоторые предыстории:[/b]

Я реализую тонкий уровень проверки поверх данных dict, загруженных из файла JSON (с json.load), и я подумал об определении нескольких псевдонимов типов и кортежей типов для типов данных, которые может содержать загруженный словарь, например:
[code]# in types.py
type Scalar = bool | int | str |float
SCALAR_TYPES = (bool, int, str, float)
[/code]
В отдельном модуле extract.py я хотел определить общую функцию для извлечения значения из словаря и проверки того, что оно является экземпляром ожидаемого типа, например:

[code]def extract_scalar[T: Scalar](data: dict, key: str, expected: type[T]) -> T: ...[/code]

или даже как:

[code]def extract_scalar[T: SCALAR_TYPES](data: dict, key: str, expected: type[T]) -> T: ... [/code]
Насколько я понимаю, первая подпись связывает T с любым из подтипов объединения типов Scalar, а вторая подпись ограничивает T одним из типов в кортеже SCALAR_TYPES.
Я протестировал оба подхода и убедился, что они работают с Python 3.14 как во время выполнения, так и во время статической проверки типов с помощью mypy и pyright.
Мне интересно, «разрешен» ли этот подход или полностью ли он поддерживается, и может ли он попасть в рамки лучших практик. Кажется, что это должно быть допустимо, тем более что оно предлагает более чистую альтернативу дублированию объединения типов (или кортежа) каждый раз, когда это необходимо (как, похоже, предлагает PEP 695, требуя, чтобы ограничения типа были буквальным выражением кортежа).