Форум сайта python.su
Доброго всем времени суток!
Я начинающий питонер и хочу прояснить для себя один очень важный вопрос, который мне в силу неопытности или недопонимания кажется больше религиозным нежели практичным.
Речь идет о проверке типа объекта в функции - является ли это признаком непонимания основ Питона достойная порицания и насмешек (нарушается концепция - все является анонимным объектом) или же это чистой воды религия вроде абсолютного неприятия goto?
Т.е. например есть функция, принимающая строку (т.е. я хочу/ожидаю получать именно строку, а не что-то иное):
def some_func( value ):
if isinstance( value, str ):
# Do something
Офлайн
Можно использовать во внешних библиотеках, (якобы интерфейс), зависит от цели.
Я почти нигде не использую проверку типа, т.к. когда вызываю 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 — такой код может быть удобней для востриятия.
Запутанные вопросы производительности для простоты опущу.
Офлайн