FakeFileWrapper doesn't inherit from io.IOBase

[Aran-Fey]

Regular file objects inherit from io.IOBase, but the fake variant doesn't. Here's a test case that fails if the fs fixture is used, but passes otherwise:

import pytest
import io, os

def test_file_mro(fs):
    try:
        with open('foo.txt', 'w') as file:
            assert isinstance(file, io.IOBase)
    finally:
        os.remove('foo.txt')

if __name__ == '__main__':
    pytest.main([__file__])

I'm working on a file-object related library, so I really need this to work correctly.

[mrbean-bremen]

Do you need that it actually inherits, or that it implements the io.IOBase methods, e.g. behaves like one?

[Aran-Fey]

I do actually need it to inherit. It's a bit hard to explain, but I have a whole bunch of functions that rely on the file objects' MRO to work correctly. The functions work differently depending on whether the file object inherits from io.TextIOBase, io.BytesIO, etc. So I actually need the whole MRO to be correct.

Here's the MRO of a file opened in text mode (open(mode='r') or open(mode='w')):

[<class '_io.TextIOWrapper'>, <class '_io._TextIOBase'>, <class '_io._IOBase'>, <class 'object'>]

A file opened with open(mode='rb'):

[<class '_io.BufferedReader'>, <class '_io._BufferedIOBase'>, <class '_io._IOBase'>, <class 'object'>]

And open(mode='wb'):

[<class '_io.BufferedWriter'>, <class '_io._BufferedIOBase'>, <class '_io._IOBase'>, <class 'object'>]

[mrbean-bremen]

Hm, I have thought about this a bit, and I'm afraid that this is not something we are able to do without a major restructuring. We aim at emulating the functionality (e.g. it shall be possible to call every method as on the original object), but not on inheritance compatibility, which is an implementation detail that may change. Generally, I do not rely on MRO checks, because it is common in Python to emulate functionality by implementing interfaces instead of inheriting from the same base class (there are the abc classes, but they serve as an interface, not a base class implementation).
@jmcgeheeiv - do you have any thoughts on this?

[Aran-Fey]

I think you're wrong about the MRO being an implementation detail. I found this in the open docs:

The type of file object returned by the open() function depends on the mode. When open() is used to open a file in a text mode ('w', 'r', 'wt', 'rt', etc.), it returns a subclass of io.TextIOBase (specifically io.TextIOWrapper). When used to open a file in a binary mode with buffering, the returned class is a subclass of io.BufferedIOBase. The exact class varies: in read binary mode, it returns an io.BufferedReader; in write binary and append binary modes, it returns an io.BufferedWriter, and in read/write mode, it returns an io.BufferedRandom. When buffering is disabled, the raw stream, a subclass of io.RawIOBase, io.FileIO, is returned.

[mrbean-bremen]

Well, you are right about the docs, though that doesn't change the fact that this will not be an easy change. I have been struggling with different IO behavior in different OSes and with different Python versions, and restructuring the code respectively is something I'm not looking forward to... so I may think about this, but don't expect something soon - sorry.

[Aran-Fey]

No problem. I'll just use real files for my tests, then.

[mrbean-bremen]

Just for reference - this is only relevant for Python 3.

[mrbean-bremen]

I have played around a bit with this, and didn't find a way to make this really working without a major rewrite. I will add a respective note to the documentation (limitations section) and close this issue.

[jmcgeheeiv]

Running your tests that use the real file system inside a Docker container would give you the ephemerality of pyfakefs plus the exact implementation details like MRO.

Free software is so refreshing--no penalty for recommending the competition.

[mrbean-bremen]

I would call it alternative, not competition 😛

Actually, I had been thinking about documenting alternatives with pros and cons, after the limitations paragraph. Docker is certainly the mostly used alternative today, at least under Linux. Maybe I'll add this before the next release...

I added a Features paragraph to the documentation with the last commit, maybe you can have a look if we are missing something here (I thought it makes sense to document the features alongside with the limitations...)