RetroSearch Browse

Sun Apr 12 12:49:37 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-April/088676.html

I've added a new proposed patch to:
http://bugs.python.org/issue5700

The idea is:
- only IOBase implements close() (though a subclass can override close
   without causing problems so long as it calls super().close() or
   calls .flush() and ._close() directly)
- change IOBase.close to call .flush() and then ._close()
- .flush() invokes super().flush() in every class except IOBase
- ._close() invokes super()._close() in every class except IOBase
- FileIO is implemented in Python in _pyio.py so that it can have the
   same base class as the other Python-implemented files classes
- tests verify that .flush() is not called after the file is closed
- tests verify that ._close()/.flush() calls are propagated correctly

On nice side effect is that inheritance is a lot easier and MI works as 
expected i.e.

class DebugClass(IOBase):
   def flush(self):
     print(<some debug info>)
     super().flush()
   def _close(self):
     print(<some debug info>
     super()._close()

class MyClass(FileIO, DebugClass): # whatever order makes sense
   ...

m = MyClass(...)
m.close()
# Will call:
#   IOBase.close()
#   DebugClass.flush()  # FileIO has no .flush method
#   IOBase.flush()
#   FileIO._close()
#   DebugClass._close()
#   IOBase._close()

Cheers,
Brian

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-April/088676.html below:

[Python-Dev] Possible py3k io wierdness