Check if object is file-like in Python

Question

File-like objects are objects in Python that behave like a real file, e.g. have a read() and a write method(), but have a different implementation. It is and realization of the Duck Typing concept.

It is considered good practice to allow a file-like object everywhere where a file is expected so that e.g. a StringIO or a Socket object can be used instead a real file. So it is bad to perform a check like this:

if not isinstance(fp, file):
   raise something

What is the best way to check if an object (e.g. a parameter of a method) is "file-like"?

Answer 1

You can try and call the method then catch the exception:

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

If you only want a read and a write method you could do this:

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

If I were you I would go with the try/except method.

Answer 2

I think the best way is to just put the read in a try block. IE

try:
    data = fp.read()
except:
    raise

Answer 3

The dominant paradigm here is EAFP: easier to ask forgiveness than permission. Go ahead and use the file interface, then handle the resulting exception, or let them propagate to the caller.

Answer 4

It is generally not good practice to have checks like this in your code at all unless you have special requirements.

In Python the typing is dynamic, why do you feel need to check whether the object is file like, rather than just using it as if it was a file and handling the resulting error?

Any check you can do is going to happen at runtime anyway so doing something like if not hasattr(fp, 'read') and raising some exception provides little more utility than just calling fp.read() and handling the resulting attribute error if the method does not exist.

Answer 5

As others have said you should generally avoid such checks. One exception is when the object might legitimately be different types and you want different behaviour depending on the type. The EAFP method doesn't always work here as an object could look like more than one type of duck!

For example an initialiser could take a file, string or instance of its own class. You might then have code like:

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

Using EAFP here could cause all sorts of subtle problems as each initialisation path gets partially run before throwing an exception. Essentially this construction mimics function overloading and so isn't very Pythonic, but it can be useful if used with care.

As a side note, you can't do the file check in the same way in Python 3. You'll need something like isinstance(f, io.IOBase) instead.

Answer 6

Under most circumstances, the best way to handle this is not to. If a method takes a file-like object, and it turns out the object it's passed isn't, the exception that gets raised when the method tries to use the object is not any less informative than any exception you might have raised explicitly.

There's at least one case where you might want to do this kind of check, though, and that's when the object's not being immediately used by what you've passed it to, e.g. if it's being set in a class's constructor. In that case, I would think that the principle of EAFP is trumped by the principle of "fail fast." I'd check the object to make sure it implemented the methods that my class needs (and that they're methods), e.g.:

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

Answer 7

def isFile(f):
    for i in dir(file):
        try:
            eval("help f."+i)
        except AttributeError:
            return False
        except:
            continue
    return True