fix integration of io with mypy

[tharvik]

See #194 for reference.

So, that should fix mypy tests. Why coping classes around? Because it is the (sadly only) way to do it, BaseIO can not inherit both BinaryIO because then TextIOWrapper would need to redefine some method (by having TextIO) but failing because not being compliant with BinaryIO. Copying seems like the best solution.

There is also some issues with mypy itself (should redefine writelines in both TextIO and BinaryIO opened here, using write_through in python 3.2 but it appears only in python 3.3).

[gvanrossum]

I will have to put off reviewing this until next week (this week I'm over-committed).

[tharvik]

I'll ping you next week then, thanks.

[gvanrossum]

What the heck I'll just merge it now. Long term this worries me -- the relationship between the class tree here, the one in the real stdlib, and the classes defined in typing.py seem all to be somewhat problematic. Ideally mypy should be able to represent such hierarchies faithfully -- I'm not sure if we're looking at changes needed to mypy, to io.pyi, or to typing.py[i].

[tharvik]

the relationship between the class tree here, the one in the real stdlib, and the classes defined in typing.py seem all to be somewhat problematic. Ideally mypy should be able to represent such hierarchies faithfully -- I'm not sure if we're looking at changes needed to mypy, to io.pyi, or to typing.py[i].

IMO, it would better to put it in typing.py, as IO[AnyStr] implement IOBase by definition, so that would mean moving most of IO[AnyStr] to IOBase, and having it only making the methods abstract.