Это - Pythonic для проверки типов аргумента функции?

В дополнение к уже упомянутым идеям вы можете захотеть «принуждать» входные данные к типу, который имеет необходимые вам операции. Например, вы можете преобразовать кортеж координат в массив Numpy, чтобы вы могли выполнять с ним операции линейной алгебры. Код принуждения довольно общий:

input_data_coerced = numpy.array(input_data)  # Works for any input_data that is a sequence (tuple, list, Numpy array…) 

Одна из причин, по которой Duck Typing поощряется на Python, заключается в том, что кто-то может обернуть один из ваших объектов, и тогда он будет выглядеть как неправильный тип, но все равно работает.

Вот пример класса, который обертывает объект. A LoggedObject действует всеми способами как объект, который он обёртывает, но когда вы вызываете LoggedObject, он регистрирует вызов до выполнения вызова.

from somewhere import log
from myclass import A

class LoggedObject(object):
    def __init__(self, obj, name=None):
        if name is None:
            self.name = str(id(obj))
        else:
            self.name = name
        self.obj = obj
    def __call__(self, *args, **kwargs):
        log("%s: called with %d args" % (self.name, len(args)))
        return self.obj(*args, **kwargs)

a = LoggedObject(A(), name="a")
a(1, 2, 3)  # calls: log("a: called with 3 args")

Если вы явно протестируете на наличие isinstance(a, A), он будет неудачным, потому что a является экземпляром LoggedObject. Если вы просто позволите утке набрать свой текст, то это сработает.

Если кто-то по ошибке передаст неверный тип объекта, то будет поднято некоторое исключение вроде AttributeError. Исключение может быть более понятным, если явно проверять типы, но в целом я думаю, что это случай выигрыша для утиных типов.

Бывают моменты, когда действительно нужно протестировать тип. Недавно я узнал, что когда вы пишете код, который работает с последовательностями, иногда вам действительно нужно знать, есть ли у вас строка, или это любой другой вид последовательности. Рассмотрим так:

def llen(arg):
    try:
        return max(len(arg), max(llen(x) for x in arg))
    except TypeError: # catch error when len() fails
        return 0 # not a sequence so length is 0

Это должно возвращать самую длинную из последовательностей, или любую последовательность, вложенную в нее. Это работает:

lst = [0, 1, [0, 1, 2], [0, 1, 2, 3, 4, 5, 6]]
llen(lst)  # returns 7

Но если вы вызовете llen("foo"), это будет повторяться навсегда до переполнения стека.

Проблема в том, что строки имеют особое свойство, что они всегда действуют как последовательность, даже когда вы берете из строки наименьший элемент; односимвольная строка все равно является последовательностью. Поэтому мы не можем написать llen() без явного теста на строку.

def llen(arg):
    if isinstance(arg, basestring):  # Python 2.x; for 3.x use isinstance(arg, str)
        return len(arg)
    try:
        return max(len(arg), max(llen(x) for x in arg))
    except TypeError: # catch error when len() fails
        return 0 # not a sequence so length is 0

Если это исключение из правила, то это нормально. Но если инжиниринг/дизайн вашего проекта вращается вокруг проверки типа каждой функции (или большинство из них) тогда, может быть, вы не хотите использовать Python, как насчет C# вместо него?

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

Об этом говорили, потому что Py3k поддерживает аннотации функций , из которых аннотации типа являются приложением. Также в Python2 была попытка прокатить проверку типов .

Я думаю, что это никогда не занимало много времени, потому что основная проблема, которую вы пытаетесь решить ("найти ошибки типа") либо тривиальна для начала (вы видите TypeError[11577]), либо довольно сложна (небольшое различие в интерфейсах типов). Плюс для того, чтобы получить его правильно , вам понадобятся типовые классы и классифицировать каждый тип на Python. В основном, это много работы. Не говоря уже о том, что вы постоянно будете делать проверки runtime.