Доброго всем времени суток!

Я начинающий питонер и хочу прояснить для себя один очень важный вопрос, который мне в силу неопытности или недопонимания кажется больше религиозным нежели практичным.
Речь идет о проверке типа объекта в функции - является ли это признаком непонимания основ Питона достойная порицания и насмешек (нарушается концепция - все является анонимным объектом) или же это чистой воды религия вроде абсолютного неприятия goto?

Т.е. например есть функция, принимающая строку (т.е. я хочу/ожидаю получать именно строку, а не что-то иное):

является ли такой подход неправильным и нарушающим принципы программирования на Питоне?
можете ли вы привести случаи очевидного нарушения базовых концепций? например, не так давно я здесь упорно пытался доказать необходимость использования “слепых” исключений для “максимального контроля за ситуацией” - самому себе то я это доказал, за что впоследствии и поплатился…

Спасибо!

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

o7412369815963
Можно использовать во внешних библиотеках, (якобы интерфейс), зависит от цели.
Я почти нигде не использую проверку типа, т.к. когда вызываю some_func всегда передаю строку (для данного примера), а если прилетела не строка, то выскочит исключение - исправлю ошибку, что-б прилетала строка.

т.е. проверку типа можно отнести к сокрытию преступления/ошибки?
вы лично считаете это серьезным недочетом или не станете даже поднимать вопрос если увидите такой код у своего коллеги? т.е. увидели - ну и что- забыл…

У себя в коде стараюсь всячески избегать явной проверки типа (лучше проверять интерфейс или концепцию).
НО, строка помоему единственный объект - подобъектами которого рекурсивно являются строки, поэтому со строками такое иногда приходится использовать.

doza_and
У себя в коде стараюсь всячески избегать явной проверки типа (лучше проверять интерфейс или концепцию).
НО, строка помоему единственный объект - подобъектами которого рекурсивно являются строки, поэтому со строками такое иногда приходится использовать.

не могли бы вы привести конкретный пример оправданного использования проверки типа (для лучшего понимания)?
что вы имели ввиду под “лучше проверять интерфейс или концепцию”? что это означает на практике?

Принимаются предложения, скажем, по реализации json.dumps без проверки типов.

можно каждому классу добавить метод __json__() который будет возвращать json представление О.о

как быть с int и str?

Обычно вместо проверки типов лучше использовать hasattr(object, attrname) (в общем-то - и есть проверка интерфейса).
Т.е для реализации json.dumps я бы использовал hasattr(object, “__json_dump__”) для объектов, которые знают, как себя задампить в json; и проверку типов для остальных - часть будет засериализовано (если json реализация знает что с ними делать), но если объект - не первое и не второе, то выбросить исключение.

Мы недавно на работе об этом говорили.
Я все еще не уверен, что hasattr лучше. Это по крайней мере не всегда верно.
В качестве примера приведу io. В двойке была путаница. Слишком много возможных атрибутов у file object. writer реализовывал обязательный write. Нужно ли каждый раз в коде перед вызовом flush проверять — а есть ли такой метод? Как быть с fileno или encoding? Если encoding отсутствует — это значит что поток бинарный или просто программист забыл определить? Другими словами, что нужно передавать в write — str или bytes?
И так далее.
Как мне кажется duck typing далеко не всегда лучший выбор.

И да, не могу не вспомнить казус с hasattr, починеный в 3.2 с подачи Юры Селиванова. Если атрибут не находился, а __getattr__ выбрасывал *любое* исключение — то hasattr считал, что атрибута нет. Теперь он так делает только если исключение было типа AttributeError.

Cчитаю, что duck typing и проверку типов нужно совмещать, смотря каждый раз поместу. Не следует городить дерево наследования только для того, чтобы проверять тип. Но если дерево получается естественным, то стоит рассмотреть возможность проверки на isinstance — такой код может быть удобней для востриятия.

Запутанные вопросы производительности для простоты опущу.