[Python-Dev] Shared ABCs for the IO implementation (original) (raw)

Guido van Rossum guido at python.org
Wed Feb 25 22:41:53 CET 2009

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 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/)

More information about the Python-Dev mailing list