Представляется маловероятным, что используемый вами синтаксис будет соответствовать подсказкам типов, как определено в PEP 484 .
Это отчасти потому, что PEP никогда не заявляет, что при использованиидопустимы произвольные выражения в качестве подсказок типа, и отчасти потому, что я не понимаю, как ваш пример действительно соответствует духу того, что пытается выполнить PEP 484.
В частности, одной из важных целей разработки экосистемы типизации Python былоподдерживать довольно строгий разрыв между "миром исполнения" и миром "статических типов". В частности, всегда должна быть возможность полностью игнорировать подсказки типа во время выполнения, но это будет невозможно, если подсказки типа иногда будут иметь побочные эффекты при оценке.
Не исключено, что кто-то в конечном итоге спроектируетПКП, который позволяет вам делать то, что вы пытаетесь сделать, и успешно спорить о его принятии, но я не думаю, что кто-то работает над таким ПКП или если есть большой спрос на него.
Возможно, более канонические способыприсоединения или записи метаданных, вероятно, было бы либо сделать явную побочную операцию явной, выполнив что-то вроде этого:
# Alternatively, make this a descriptor class if you want to do
# even fancier things: https://docs.python.org/3/howto/descriptor.html
def magic() -> Any:
# magic here
class Foo:
value: int = magic()
def __init__(self, value):
self.value = value
..., либо использовать новый тип Annotated, описанный в, по-видимому, простопринято PEP 593 , что позволяет сосуществовать подсказкам типа и произвольной информации не-подсказки типа:
# Note: it should eventually be possible to import directly from 'typing' in
# future versions of Python, but for now you'll need to pip-install
# typing_extensions, the 'typing' backport.
from typing_extensions import Annotated
def magic():
# magic here
class Foo:
value: Annotated[int, magic()]
def __init__(self, value):
self.value = value
Основное предостережение при последнем подходе заключается в том, что я не верю Пихармувсе еще поддерживает подсказку типа Annotated, учитывая, что она очень новая.
Если оставить все это в стороне, этоОр, отмечая, что не обязательно неправильно просто отвергать PEP 484 и продолжать использовать то, что понимает Пихарм. Меня немного озадачивает, что Pycharm, очевидно, может понять ваш пример (возможно, это артефакт реализации того, как Pycharm реализует анализ типов?), Но если он работает для вас и если адаптация вашей кодовой базы для соответствия PEP 484 слишком болезненна, этоможет быть разумно просто использовать то, что у вас есть.
И если вы хотите, чтобы ваш код был доступен для использования другими разработчиками, которые используют подсказки типа PEP 484, вы всегда можетерешите распространять файлы-заглушки pyi вместе с вашим пакетом, как описано в PEP 561 .
Для создания этих файлов-заглушек потребуется немало усилий, но заглушки действительно дают возможностькод, который отказался от использования PEP 484 для взаимодействия с кодом, который не имеет.