

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise

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"?

share|improve this question
up vote 25 down vote accepted

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 and handling the resulting attribute error if the method does not exist.

share|improve this answer
why what about operators like __add__, __lshift__ or __or__ in custom classes? (file object and API: ) – n611x007 Sep 8 '12 at 12:56
@naxa:So what exactly about those operators? – martineau Jan 20 '15 at 15:43
Often just trying it works but I don't buy the Pythonic maxim that if it's hard to do in Python then it's wrong. Imagine you are passed an object and there are 10 different things you might do with that object depending on its type. You're not going to try each possibility and handle the error until you finally get it right. That would be totally inefficient. You don't necessarily need to ask, what type is this, but you do need to be able to ask does this object implement interface X. – jcoffland Sep 17 '15 at 6:19
The fact that the python collections library provides what might be called "interface types" (e.g., sequence) speaks to the fact that this is often useful, even in python. In general, when someone asks "how to foo", "don't foo" is not a highly satisfactory answer. – AdamC Oct 23 '15 at 19:13

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.

share|improve this answer
+1: If x isn't file-like, then will raise it's own exception. Why write an extra if-statement? Just use the object. It will either work or break. – S.Lott Nov 2 '09 at 13:48
Don't even handle the exception. If someone passed in something that doesn't match the API you expect, it's not your problem. – habnabit Nov 2 '09 at 22:12
@Aaron Gallagher: I am not sure. Is your statement true even if it is hard for me to preserve an consistent state? – dmeister Nov 4 '09 at 11:19
To preserve a consistent state you can use "try/finally" (but no except!) or the new "with" statement. – drxzcl Nov 7 '09 at 12:25
This is also consistent with a "Fail fast and fail loudly" paradigm. Unless you're meticulous, explicit hasattr(...) checks can occasionally cause a function/method to return normally without performing its intended action. – Ben Burns Aug 22 '11 at 15:09

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
            # 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.

share|improve this answer
Good point...and I think the only justifiable use of the file built-in I've ever seen. – martineau Jan 20 '15 at 16:13

It's often useful to raise an error by checking a condition, when that error normally wouldn't be raised until much later on. This is especially true for the boundary between 'user-land' and 'api' code.

You wouldn't place a metal detector at a police station on the exit door, you would place it at the entrance! If not checking a condition means an error might occur that could have been caught 100 lines earlier, or in a super-class instead of being raised in the subclass then I say there is nothing wrong with checking.

Checking for proper types also makes sense when you are accepting more than one type. It's better to raise an exception that says "I require a subclass of basestring, OR file" than just raising an exception because some variable doesn't have a 'seek' method...

This doesn't mean you go crazy and do this everywhere, for the most part I agree with the concept of exceptions raising themselves, but if you can make your API drastically clear, or avoid unnecessary code execution because a simple condition has not been met do so!

share|improve this answer
I agree, but along the lines of not going crazy with this everywhere - a lot of these concerns should shake out during testing, and some of the "where to catch this/how to display to user" questions will be answered by usability requirements. – Ben Burns Aug 22 '11 at 15:16

For 3.1+, one of the following:

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

For 2.x, "file-like object" is too vague a thing to check for, but the documentation for whatever function(s) you're dealing with will hopefully tell you what they actually need; if not, read the code.

As other answers point out, the first thing to ask is what exactly you're checking for. Usually, EAFP is sufficient, and more idiomatic.

The glossary says "file-like object" is a synonym for "file object", which ultimately means it's an instance of one of the three abstract base classes defined in the io module, which are themselves all subclasses of IOBase. So, the way to check is exactly as shown above.

(However, checking IOBase isn't very useful. Can you imagine a case where you need to distinguish an actual file-like read(size) from some one-argument function named read that isn't file-like, without also needing to distinguish between text files and raw binary files? So, really, you almost always want to check, e.g., "is a text file object", not "is a file-like object".)

For 2.x, while the io module has existed since 2.6+, built-in file objects are not instances of io classes, neither are any of the file-like objects in the stdlib, and neither are most third-party file-like objects you're likely to encounter. There was no official definition of what "file-like object" means; it's just "something like a builtin file object", and different functions mean different things by "like". Such functions should document what they mean; if they don't, you have to look at the code.

However, the most common meanings are "has read(size)", "has read()", or "is an iterable of strings", but some old libraries may expect readline instead of one of those, some libraries like to close() files you give them, some will expect that if fileno is present then other functionality is available, etc. And similarly for write(buf) (although there are a lot fewer options in that direction).

share|improve this answer
This is a useful answer -- thanks! – AdamC Oct 23 '15 at 19:15

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

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.

share|improve this answer
I'd suggest switching the order of the examples. try is always the first choice. The hasattr checks are only -- for some really obscure reason -- you can't simply use try. – S.Lott Nov 2 '09 at 14:07
@S.Lott Good point – Nadia Alramli Nov 2 '09 at 14:08
I suggest using instead of in order to avoid put all code in the try block if you want to process the data from fp subsequently. – Meow Dec 12 '14 at 12:19
Note that with big files will immediately increase memory usage. – Kyrylo Perevozchikov May 19 '15 at 13:21

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
share|improve this answer
Why getattr(file, 'read') instead of just This does the exact same thing. – abarnert Jul 17 '14 at 19:39
More importantly, this check is wrong. It will raise when given, say, an actual file instance. (Methods of instances of builtin/C-extension types are of type builtin_function_or_method, while those of old-style classes are instancemethod). The fact that this is an old-style class, and that it uses == on types instead of ininstance or issubclass, are further problems, but if the basic idea doesn't work, that hardly matters. – abarnert Jul 17 '14 at 19:44

Your Answer


