PEP 3107 — Function Annotations

Иногда/кому-то нужно, иногда/кому-то не нужно. Стандарт старый, срачей обсуждений было уже много - ничего нового здесь не добавят.

Читать: https://mail.python.org/pipermail/python-ideas/2012-December/018088.html

Зачем оно нужно?

Аннотировать функции. В том числе и для статической проверки типов. Причём, для этого не обязательно аннотировать всё, есть сподвижки по тайпчекерам которые умеют выводить типы.

Ещё можно проверять типы в рантайме, это гораздо проще.

Я как-то этим баловался и, в итоге, забил: особого профита не почувствовал.

Зачем оно нужно?

Вот зачем:

might be used to provide typechecking for Python functions and methods

PEP

Очередной указ фюрера?

Как минимум для нормальной поддержки автодополнения в IDE всяких.

Прочитал, удивился.

почитай про EAFP, удивись еще больше.

Не вижу в этой фиче никакого профита или удобства. «описать» что нужно скармливать функции всегда можно в документации, ошибочное скармливание функции не того типа всегда может породить эксепшн.

почитай лучше Гв-до http://www.artima.com/weblogs/viewpost.jsp?thread=85551 http://www.artima.com/weblogs/viewpost.jsp?thread=86641 http://www.artima.com/weblogs/viewpost.jsp?thread=87182 http://www.artima.com/weblogs/viewpost.jsp?thread=89161

этот ваш лоркод...
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
http://www.artima.com/weblogs/viewpost.jsp?thread=89161

В таком виде, как представленно в PEPе, нафиг не нужно.

Выглядит как костыль для сглаживания недостатков из-за отсутствия статической типизации

К типизации этот костыль не имеет никакого отношения. Это всего лишь метод присоединения абстрактных метаданных к аргументу без формализации их назначения. Т.е. будет каша в стиле пыха.

Если бы было однозначно сказано, что можно присоеденить в отдельный слот только тип, в другой только описание и т.п., то было бы совсем другое дело.

предательство основ

лiл

Если бы было однозначно сказано, что можно присоеденить в отдельный слот только тип, в другой только описание и т.п., то было бы совсем другое дело.

Пример кода в студию!

эдакое предательство основ и перебежка в стан врага

Что?

Питонисты, знающие хотя бы один статически типизированный язык, каково ваше мнение?

К статически типизированным языкам аннотации не имеют никакого отношения

К статически типизированным языкам аннотации не имеют никакого отношения

если бы вы осилили пару ссылок, приведённых выше, то, вероятно, догадались бы, что это подозрительно похоже на контроль типов из статически типизированных языков.

Только в питоне это смотрится странно - как будто признание, что изначально выбранная стратегия динамической типизации была ошибочной. Я и называю это перебежкой в стан врага :)

Это так сказать мой непредвзятый взгляд.

Пример кода в студию!

Если спрашиваешь как я себе это представляю в труёвом варианте, то как-то так:

def name(arg1, @Foo arg2: 'second arg', @(Foo, Bar) arg3)

{'arg2': tuple(types = (<class '__main__.Foo'>,), desc = 'second arg'), 'arg3': tuple(types = (<class '__main__.Foo'>, <class '__main__.Bar'>))}

Вы не поверите, но в некоторых языках со статической типизацией оно тоже есть, и считается вовсе не костылем, а весьма продвинутой фичей. Например, Ada 2012.

Громоздко/

Нет, не громоздко. Точно так же, как и в PEPе из топика.

def name(arg1, @Foo arg2: 'second arg', @(Foo, Bar) arg3)

Что это всё значит?

Следующей строчкой дано описание что это значит. Тип(ы) аргумента (Foo, Bar) и прочая дрянь.

Докстринги-выражения для аргументов? Но зачем?

Проблема с аннотациями как раз в том, что они не стандартизированы, так что сделать универсальный инструмента анализа не получится. Бесполезная фишка, похерившая полезную идею.

Докстринги-выражения для аргументов? Но зачем?

Например, статически проверять типы.

Статически - это когда?

У тебя видимо очень слабое представление о системах типов.

Как предлагается статически проверять типы с помощью динамически генерируемого словаря?

Статически - это когда?

Издеваешься, да?

Ни разу.

Не представляю, каким образом без дополнительного слоя синтаксиса и/или договорённостей из этого сделать полноценную проверку в смысле статической типизации.

профит тут с того, что это помогает редакторам типа PyDev легче угадывать тип переменных.

Я как раз говорил о договоренностях (точнее, их отсутствии).

Так когда проверки то будут проходить?

Это просто сахар над декоратором, валидирующим аргументы и результат? Или для полутора калеченных ситуаций тривиальной композиции интерпретатор сможет выругаться в момент инициализаций?

Так когда проверки то будут проходить?

До выполнения.

Это просто сахар над декоратором, валидирующим аргументы и результат?

Ты правда не понимаешь, что значит «статическая проверка типов»?

инициализаций

WUT

До выполнения чего? Отдельным проходом, вангующим о типизациях вызовов?

Я прекрасно понимаю, что такое статическая проверка типов. И это позволяет мне осозновать, что тупой экспрешн, вычисляемый при инициализации функции не достаточен для неё. То, что тебе это неясно меня поражает.

До выполнения.

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

в питоне невозможна полноценная проверка типов до выполнения

Смотря что называть «полноценностью», но лично я обошелся бы подмножеством языка.

В лучшем случае будет инструмент-чекер, который будет в некоторых случаях указывать на сделанные ошибки

Да, без инструмента-чекера никуда.

профит тут с того, что это помогает редакторам типа PyDev легче угадывать тип переменных.

def name(arg: 10):...

Сильно помогло угадать?

Я прекрасно понимаю, что такое статическая проверка типов. И это позволяет мне осозновать, что тупой экспрешн, вычисляемый при инициализации функции не достаточен для неё.

Чего именно тебе недостаточно?

def foo(a: "int"):
   print a

foo(1) # ОК
foo("bar") # fail, str instead of int
foo(None) # fail, NoneType instead of int

И когда будет проведена проверка?

Что будет с foo(1 if check_smth «xyu» else)?

Сильно помогло угадать?

если программист - безголовый, то ему - ничего не поможет

если программист - безголовый, то ему - ничего не поможет

вот как ты, например, не осиливний пролистать PEP?

Сильно помогло угадать?

помогло. Параметр arg всегда должен быть равен 10

И когда будет проведена проверка?

А подумай.

Что будет с foo(1 if check_smth «xyu» else)?

error: type mismatch: attempt to pass value of type  `int | str' instead of `int'

А подумай.

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

Что будет c foo(eval(smth))?

вот как ты, например, не осиливний пролистать PEP?

я пролистал этот pep ещё несколько лет назад. а чтобы понять для чего он нужен, достаточно прочитать раздел «Rationale» в нём. если кто-то все равно ни черта не понял, то это их (и твоя) половые проблемы тчк

Судя по всему, ты сам не представляешь.

Судя по всему, ты не представляешь, когда проводится статическая проверка типов %)

Что будет c foo(eval(smth))?

error: type mismatch: attempt to pass value of type `object' instead of `int'

не в питоне. Это какой-то другой язык будет. Strict python какой-то.

Всё с тобой и с пепом понятно.

Это какой-то другой язык будет. Strict python какой-то.

В общем, да. Но пока Strict Python является точным подмножеством Python, всё нормально.

Всё с тобой и с пепом понятно.

Ради справедливости: это всего лишь одно из возможных применений аннотаций.

пока Strict Python является точным подмножеством Python

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