Как описать аргументы функции в языках с динамической типизацией?

Мой вопрос больше ориентирован на Python, но также может касаться JavaScript или других языков сценариев.

Я обычно разрабатываю со статически типизированными языками (Java, C++, ActionScript, ...).

Мне нравится время от времени использовать Python, и мне также иногда нужно использовать JavaScript. Это языки с динамической типизацией. В этом нет ничего плохого, но обычно у меня много головной боли, чтобы понять, какие параметры нужны в функции или в методе. Это происходит, даже если это мой собственный код с некоторыми строками документации! Может быть, потому что глаз должен смотреть куда-то еще, кроме определения функции.

Конечно, ответ должен быть в документации. Но иногда это вообще неясно, или из-за использования утиной печати документацию может быть трудно написать ("первый параметр - это функция, которая должна иметь метод quack() и перья (arg) метод, где arg — строка"). Чего бы мне очень хотелось, так это своего рода описания аргументов внутри самого языка (даже если бы оно было необязательным, как в ActionScript).

Каковы ваши наилучшие методы однозначного описания аргументов функции/метода?

Как насчет создания специального декоратора (при использовании Python), целью которого будет проверка типа данных, когда мы их используем (но поскольку он будет использоваться во время выполнения, а не во время записи, в любом случае, какой в ​​этом смысл)?

Как вы думаете, это не должно быть проблемой? Что выполнение большего, чем текущая строка документации, может сбить с толку разработчика, или что мой разум слишком ориентирован на статическую типизацию?


python javascript arguments code-documentation dynamic-typing
person Vincent Hiribarren    schedule 29.04.2012    source источник
comment
Забудьте о таком декораторе. Это бесполезно для документации, очень сложно (если сделано правильно), вводит большие накладные расходы, даже в этом случае ставит под угрозу утиную печать и не дает вам никаких обычных преимуществ проверки типов (проверка без запуска программы, вышеупомянутая документация, оптимизация и т. д.). .). Вы возражаете, это слишком ориентировано на статическую типизацию.   -  person    schedule 29.04.2012
comment
Может быть, это действительно так :) Но иногда у меня создается впечатление, что я трачу свое время на изучение документации некоторых библиотек Python только для того, чтобы знать, какой аргумент я должен привести; тогда как мне просто нужно посмотреть на сигнатуру функции/метода со статической типизацией. Я знаю, что динамическая типизация позволяет обойти некоторые ограничения языков со статической типизацией, но все же, если она подразумевает нечеткое понимание использования библиотеки, я чувствую, что теряю время.   -  person Vincent Hiribarren    schedule 29.04.2012

Ответы (2)


arrow_upward
2
arrow_downward

Я не знаю о Javascript, но Python имеет необязательный function annotations начиная с версии 3, который выглядит так:

def haul(item: Haulable, *vargs: PackAnimal) -> Distance:

or:

def compile(source: "something compilable",
            filename: "where the compilable thing comes from",
            mode: "is this a single statement or a suite?"):

см. PEP для получения дополнительной информации.

Они доступны во время выполнения и даже могут использоваться для type checking.

person ch3ka    schedule 29.04.2012
comment
Я полагаю, что ОП спрашивает о стиле письма, который он должен использовать, в то время как вы предлагаете место, где он может разместить свое письмо… Так что я не уверен, что это действительно отвечает на вопрос. - person David Wolever; 29.04.2012
comment
Он спросил, а как насчет создания специального декоратора (при использовании Python), целью которого будет проверка типа данных, когда мы его используем (но поскольку он будет использоваться во время выполнения, а не во время записи, какой в ​​этом смысл)? - аннотации функций решают этот вопрос, поскольку они служат обоим вариантам использования. - person ch3ka; 29.04.2012
comment
Аааа, да, совсем забыл об этой возможности Python 3. Вы совершенно правы. Тем не менее, я должен пока использовать ветку 2.x (из-за некоторых библиотек), и ответ может быть интересен для нее. Я буду продолжать смотреть и голосовать за другие ответы :) - person Vincent Hiribarren; 29.04.2012

arrow_upward
1
arrow_downward

Почему утиная типизация затрудняет написание документации?

Когда вы пишете функцию, вы пишете ее, предполагая, что аргументы имеют определенный тип или подтверждают определенный интерфейс… Так что просто задокументируйте это.

Например, если у вас есть метод swim_in_pond(duck), нет необходимости документировать «duck должен иметь методы quack(), swim() и dive()» — в большинстве случаев вполне достаточно сказать «duck является экземпляром Duck». Или, если для вас важно задокументировать «Duck-подобный» интерфейс, я счел полезным объявить базовый класс, который служит документацией:

class DuckBase(object):
    def quack(self):
        """ Makes the duck quack. """

    def swim(self):
        """ Swims around.
            Assumes the duck is already in water.
            Updates the duck's position. """

    def dive(self):
        """ Dives either as deep as possible (either until the duck runs out of
            air, or it hits the bottom of the pond). """
person David Wolever    schedule 29.04.2012
comment
Это на самом деле утиная печать? - person Dan Roberts; 29.04.2012
comment
@DanRoberts Если swim_in_pond принимается любой объект с этим (потерянным, неформально определенным) интерфейсом, это так. - person ; 29.04.2012