[Python-Dev] Shared ABCs for the IO implementation

[Guido van Rossum]

On Wed, Feb 25, 2009 at 1:31 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Guido van Rossum wrote:
>> On Wed, Feb 25, 2009 at 1:03 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> Guido van Rossum <guido <at> python.org> writes:
>>>> Without a shared ABC you'd defeat the whole point of having ABCs.
>>>>
>>>> However, importing ABCs (which are defined in Python) from C code
>>>> (especially such fundamental C code as the I/O library) is really
>>>> subtle and best avoided.
>>>>
>>>> In io.py I solved this by having a Python class inherit from both the
>>>> ABC (RawIOBase) and the implementation (_fileio._FileIO).
>>> My plan (let's call it "the Operation") is to define the ABCs in Python by
>>> deriving the C concrete base classes (that is, have io.XXXIOBase derive
>>> _io.XXXIOBase). This way, by inheriting io.XXXIOBase, user code will benefit
>>> both from ABC inheritance and fast C concrete implementations.
>>
>> However that's hardly an ABC. You need to provide a path for someone
>> who wants to implement the ABC without inheriting your implementation.
>
> Don't they already have that through register()?

I'd like the ABCs to remain just as abstract or concrete as they are
in 3.0. As long as the C version implements the same methods with the
same semantics as the 3.0 io.py I don't care.

> However, the other problem with setting up the inheritance as Antoine
> suggests is that it makes it impossible to import a pure Python version
> of the module. Once the Python code inherits from something provided
> only by the C module then the C version isn't optional any more.

I think this should be taken care of by having separate _pyio.py and
_cio.py modules which are unified by io.py, right? (Or whatever naming
convention is agreed upon; I skipped that thread. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)