PyFence: верификация типов для Python

[@Ghostwriter]

В PyCharm есть аналогичный инспектор, сильно помогает. Случайно не ваш?
Поддерживает ли PyFence множественные варианты с ":type obj: :class:`project.entities.MyClass` or None" и inline-нотацию типа ":param int number: description"? У PyCharm со вторым проблемы.

[@hardex]

Множественные поддерживаются через запятую (см. документацию, в ней примеры). Насколько я знаю, inline-нотация не является валидной с точки зрения sphinx.
В отличие от PyCharm, который делает статический анализ, PyFence делает проверки во время выполнения, безо всяких исключений.

[@Ghostwriter]

Все-таки inline валидный sphinx-doc.org/domains.html#info-field-lists

[@hardex]

Познавательно. Сейчас добавлю!

[@hardex]

Готово.

[@seriyPS]

Не очень сочетается с duck-typing. Ведь без PyFence достаточно было чтобы у объекта number был метод .as_integer_ratio() чтобы код работал, а с fence придётся обязательно наследоваться от float, иначе ругнётся.
Конечно, на практике этим не часто пользуются, но идея именно в этом.

[@hardex]

Пример — это изначально фиговый код, в котором должна была быть проверка типа аргумента (или хотя бы hasattr('as_integer_ratio')). Наследоваться от float — это пожалуй, еще хуже.

[@seriyPS]

Пример — это нормальный код. Или вы серьёзно считаете, что «не-фиговый код» должен быть таким:

    def format(self, number):
        if hasattr(number, 'as_integer_ratio'):
            return '%i/%i' % number.as_integer_ratio()
        else:
            #?????

docs.python.org/2/glossary.html#term-eafp

В наследовании от float почему-то не вижу ничего плохого :-\

[@hardex]

Я считаю что нормальный код должен начинаться с

if type(number) is not float:
    raise ArgumentError(...)

[@seriyPS]

Тогда Python вам противопоказан, ИМХО.

[@hardex]

Скажите тогда то же самое разработчикам Django, например.

~/django ⭠ master $ ack-grep 'raise TypeError' . | wc -l
157

[@seriyPS]

Ну, не так уж много на 76305 строк кода =)

Две трети из этого в contrib/gis почему-то.

Ладно, я всего лишь высказываю своё мнение. То что кто-то с ним не согласен меня устраивает.

[@hardex]

Я же не предлагаю форсить типы аргументов повсеместно. Однако если функция неспособна работать с каким-либо типом, кроме определенного, будет человечно выдать программисту ValueError, а не заставлять лезть в ее потроха и выяснять, почему начинают сыпаться AttributeError/TypeError еще на пять фреймов ниже.

[@int19h]

Можно не наследоваться от float, а добавить абстрактный класс с данным методом.

[@monolithed]

В Python 3.3.3 появилась очень мощная работа с интроспекцией и сигнатурой функций Function Signature Object, пример из PEP 362:

@checktypes
def test(a:int, b:str) -> int:
      return int(a * b)

[@int19h]

Только вот декоратор checktypes не входит в стандартную библиотеку, увы. Его придется таскать везде с собой.

[@monolithed]

К сожалению да (

[@corristo]

Я джва года такое для Objective C жду