Является ли обычной / хорошей практикой проверять значения типов в Python?

Question

Часто ли в Python продолжают тестировать значения типов при работе в режиме ООП?

class Foo():
    def __init__(self,barObject):
        self.bar = setBarObject(barObject)

    def setBarObject(barObject);
        if (isInstance(barObject,Bar):
            self.bar = barObject
        else:
            # throw exception, log, etc.

class Bar():
    pass

Или я могу использовать более свободный подход, например:

class Foo():
    def __init__(self,barObject):
        self.bar = barObject

class Bar():
    pass

Answer 1

Нет, на самом деле, в подавляющем большинстве случаев не для проверки значений типа, как в вашем втором подходе.Идея состоит в том, что клиент вашего кода (то есть какой-то другой программист, который использует ваш класс) должен иметь возможность передавать любой тип объекта, который имеет все соответствующие методы или свойства.Если это не экземпляр какого-то определенного класса, это нормально;ваш код никогда не должен знать разницу.Это называется утка, набирающая , из-за пословицы «Если она крякает как утка и летит как утка, это может быть и утка» (ну, это не настоящая пословица, но я понялоб этом я думаю)

В одном месте вы увидите это в стандартной библиотеке со всеми функциями, которые обрабатывают ввод или вывод файла.Вместо того, чтобы требовать фактический объект file, они будут использовать для записи все, что реализует метод read() или readline() (в зависимости от функции) или write().На самом деле вы часто будете видеть это в документации, например, с tokenize.generate_tokens, который я только что рассмотрел ранее сегодня:

Генератор generate_tokens() требуетодин аргумент, readline , который должен быть вызываемым объектом, который обеспечивает тот же интерфейс, что и метод readline() встроенных файловых объектов (см. раздел File Objects ).Каждый вызов функции должен возвращать одну строку ввода в виде строки.

Это позволяет вам использовать объект StringIO (например, файл в памяти) или что-то более странное, например диалоговое окно.вместо реального файла.

В своем собственном коде просто получите доступ к любым свойствам объекта, который вам нужен, и если это неправильный тип объекта, одно из необходимых вам свойств не будет там иэто вызовет исключение.

Answer 2

Я думаю, что хорошей практикой является проверка input для типа.Разумно предположить, что если вы попросите пользователя указать один тип данных, который он может дать вам другой, то вам следует написать код для защиты от этого.

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

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

Answer 3

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

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

Answer 4

Если ваша альтернатива проверке типов - это еще одна, содержащая обработку исключений, тогда вам действительно стоит подумать о том, чтобы утка набрала один уровень, поддерживая столько объектов с помощью методов, которые вам нужны из ввода, и работая внутри try. Вы можете, кроме (и за исключением как можно более конкретно), что. Конечный результат будет не таким, как у вас, но гораздо более универсальным и Pythonic.

На все остальное, что нужно было сказать о фактическом вопросе, является ли это обычной / хорошей практикой или нет, я думаю, что Дэвид отлично ответил.