Перевірте, чи об’єкт схожий на файл у Python

Question 1

Файлоподібні об'єкти - це об'єкти в Python, які ведуть себе як справжній файл, наприклад, мають метод read () та метод запису (), але мають іншу реалізацію. Це і реалізація концепції набору качки .

Вважається доброю практикою дозволяти файлоподібний об'єкт скрізь, де очікується файл, щоб, наприклад, StringIO або Socket-об'єкт можна було використовувати замість реального файлу. Тож погано виконувати перевірку, як це:

if not isinstance(fp, file):
   raise something

Який найкращий спосіб перевірити, чи є об’єкт (наприклад, параметр методу) «файловим»?

Question 2

Зазвичай взагалі не є доброю практикою мати такі перевірки у своєму коді, якщо у вас немає спеціальних вимог.

У Python набір тексту динамічний, чому ви відчуваєте необхідність перевіряти, чи об'єкт схожий на файл, а не просто використовувати його, ніби це файл, і обробляти отриману помилку?

Будь-яка перевірка, яку ви можете зробити, все одно відбуватиметься під час виконання, тому, роблячи щось на зразок if not hasattr(fp, 'read')та створюючи якийсь виняток, ви отримуєте трохи більше корисності, ніж просто виклик fp.read()та обробка отриманої помилки атрибута, якщо метод не існує.

Question 3

Для версій 3.1+ одне з наступного:

isinstance(something, io.TextIOBase)
isinstance(something, io.BufferedIOBase)
isinstance(something, io.RawIOBase)
isinstance(something, io.IOBase)

Для 2.x "файлоподібний об'єкт" - занадто розмита річ, щоб перевіряти, але документація щодо будь-яких функцій, з якими ви маєте справу, сподіваємось, розповість вам, що їм насправді потрібно; якщо ні, прочитайте код.

Як вказують інші відповіді, перше, що потрібно запитати, це те, що саме ви перевіряєте. Зазвичай EAFP є достатнім і більш ідіоматичним.

Словник каже «файл-подібний об'єкт» є синонімом «файлового об'єкта», який в кінцевому рахунку означає , що це екземпляр одного з трьох абстрактних базових класів , визначених у в ioмодулі , які самі по собі всі підкласи IOBase. Отже, спосіб перевірки - саме такий, як показано вище.

(Однак перевірка IOBaseне надто корисна. Чи можете ви уявити випадок, коли вам потрібно відрізнити фактичний файл, схожий на read(size)якусь функцію з одним аргументом, названу readне файлоподібно, без необхідності також розрізняти текстові файли та необроблені двійкові файли? Отже, насправді ви майже завжди хочете перевірити, наприклад, "це об'єкт текстового файлу", а не "є файлоподібний об'єкт".)

Для 2.x, хоча ioмодуль існує з 2.6+, вбудовані файлові об'єкти не є екземплярами ioкласів, а також жоден з файлоподібних об'єктів у stdlib, а також більшість сторонніх файлоподібних об'єктів, які ви швидше за все зіткнеться. Не було офіційного визначення того, що означає "файлоподібний об'єкт"; це просто "щось на зразок вбудованого об'єкта файлу ", а різні функції означають різні речі під "подобається". Такі функції повинні документувати, що вони означають; якщо вони цього не роблять, вам слід поглянути на код.

Однак найпоширенішими значеннями є "має read(size)", "має read()" або "це ітерація рядків", але деякі старі бібліотеки можуть очікувати readlineзамість одного з них, деякі бібліотеки люблять close()файли, які ви їм надаєте, деякі очікують, що якщо filenoприсутній, тоді доступна інша функціональність тощо. І так само для write(buf)(хоча варіантів у цьому напрямку набагато менше).

Question 4

Як казали інші, вам слід взагалі уникати таких перевірок. Одним винятком є випадки, коли об'єкт може бути законно різних типів, і ви хочете по-різному поводитися залежно від типу. Метод EAFP тут не завжди працює, оскільки об’єкт може виглядати як більше ніж один тип качок!

Наприклад, ініціалізатор може взяти файл, рядок або екземпляр власного класу. Тоді у вас може бути такий код:

class A(object):
    def __init__(self, f):
        if isinstance(f, A):
            # Just make a copy.
        elif isinstance(f, file):
            # initialise from the file
        else:
            # treat f as a string

Використання EAFP тут може спричинити всі види тонких проблем, оскільки кожен шлях ініціалізації частково запускається перед створенням винятку. По суті, ця конструкція імітує перевантаження функції, і тому не надто пітонічна, але може бути корисною, якщо використовувати її обережно.

Як додаткову примітку, ви не можете виконати перевірку файлів однаково в Python 3. Натомість вам знадобиться щось на зразок isinstance(f, io.IOBase).

Question 5

Домінуючою парадигмою тут є EAFP: легше просити прощення, ніж дозволу. Продовжуйте використовувати файловий інтерфейс, потім обробляйте виняток, що вийшов, або нехай вони поширюються на абонента.

Question 6

Часто корисно викликати помилку, перевіряючи умову, коли ця помилка зазвичай не виникає набагато пізніше. Це особливо справедливо для межі між "користувачем-землею" та "api" кодом.

Ви б не поставили металошукач у поліцейському відділенні біля вихідних дверей, а поставили біля входу! Якщо не перевірка умови означає, що може статися помилка, яка могла бути виявлена на 100 рядків раніше, або в супер-класі, замість того, щоб бути піднятою в підкласі, тоді я кажу, що немає нічого поганого в перевірці.

Перевірка правильних типів також має сенс, коли ви приймаєте більше одного типу. Краще викликати виняток, який говорить: "Мені потрібен підклас базового рядка, АБО файл", ніж просто виняток, оскільки деяка змінна не має методу "шукати" ...

Це не означає, що ви божеволієте і робите це скрізь, здебільшого я погоджуюся з концепцією винятків, які самі по собі роблять, але якщо ви можете різко зрозуміти свій API або уникнути непотрібного виконання коду, оскільки проста умова не виконується роби так!

Question 7

Ви можете спробувати викликати метод, а потім зловити виняток:

try:
    fp.read()
except AttributeError:
    raise something

Якщо ви хочете лише метод читання та запису, ви можете зробити це:

if not (hasattr(fp, 'read') and hasattr(fp, 'write')):
   raise something

Якби я був на вашому місці, я пішов би за методом try / Osim.

Question 8

За більшості обставин, найкращий спосіб вирішити це - не зробити. Якщо метод бере файлоподібний об'єкт, і виявляється, що переданий ним об'єкт не є, виняток, який виникає, коли метод намагається використовувати об'єкт, є не менш інформативним, ніж будь-який виняток, який ви могли б викликати явно.

Існує принаймні один випадок, коли ви можете зробити подібну перевірку, і саме тоді об’єкт не використовується відразу тим, у що ви його передали, наприклад, якщо він встановлений у конструкторі класу. У такому випадку я міг би думати, що принцип EAFP сформульований принципом "швидко провалитися". Я б перевірив об’єкт, щоб переконатися, що він реалізував методи, які потрібні моєму класу (і чи є вони методами), наприклад:

class C():
    def __init__(self, file):
        if type(getattr(file, 'read')) != type(self.__init__):
            raise AttributeError
        self.file = file

Question 9

Нарешті, я натрапив на ваше запитання, коли писав openподібну функцію, яка могла прийняти ім’я файлу, дескриптор файлу або попередньо відкритий схожий на файл об’єкт.

Замість тестування readметоду, як пропонують інші відповіді, я закінчив перевіряти, чи можна відкрити об’єкт. Якщо це можливо, це рядок або дескриптор, і я маю на руках дійсний файлоподібний об’єкт з результату. Якщо openпіднімає a TypeError, то об’єкт - це вже файл.