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(
Nick Coghlan wrote:
Brian Quinlan wrote:
- you need the cooperation of your subclasses i.e. they must call
super().flush() in .flush() to get correct close behavior (and this
represents a backwards-incompatible semantic change)
Are you sure about that? Going by the current _pyio semantics
Brian Quinlan wrote:
> - you need the cooperation of your subclasses i.e. they must call
> super().flush() in .flush() to get correct close behavior (and this
> represents a backwards-incompatible semantic change)
Are you sure about that? Going by the current _pyio semantics that
Antoine poste
Alex Martelli wrote:
> Queue.Queue in 2.* (and queue.Queue in 3.*) is like that too -- the
> single leading underscore meaning "protected" ("I'm here for subclasses
> to override me, only" in C++ parlance) and a great way to denote "hook
> methods" in a Template Method design pattern instance. Bas
James Y Knight wrote:
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan sweetapp.com> writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python version.
I
Antoine Pitrou wrote:
Your proposal looks sane, although the fact that a semi-private method
(starting with an underscore) is designed to be overriden in some classes is a
bit annoying.
The only other way I can see is to give up any attempt
in the base class to ensure that flushing occurs befor
On Sun, Apr 5, 2009 at 3:54 PM, Nick Coghlan wrote:
> Antoine Pitrou wrote:
> > James Y Knight fuhm.net> writes:
> >> It seems that a separate method "_internal_close" should've been
> >> defined to do the actual closing of the file, and the close() method
> >> should've been defined on the base
Antoine Pitrou wrote:
> James Y Knight fuhm.net> writes:
>> It seems that a separate method "_internal_close" should've been
>> defined to do the actual closing of the file, and the close() method
>> should've been defined on the base class as "self.flush();
>> self._internal_close()" and ne
Brian Quinlan wrote:
if not self.__closed:
try:
-self.flush()
+IOBase.flush(self)
except IOError:
pass # If flush() fails, just give up
self.__closed = True
That doesn't seem like a good idea to me at
James Y Knight fuhm.net> writes:
>
> It seems that a separate method "_internal_close" should've been
> defined to do the actual closing of the file, and the close() method
> should've been defined on the base class as "self.flush();
> self._internal_close()" and never overridden.
I'm comp
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan sweetapp.com> writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python
version.
I suppose it's so that
Antoine Pitrou wrote:
Brian Quinlan sweetapp.com> writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python version.
I suppose it's so that people who only override flush()
Brian Quinlan sweetapp.com> writes:
>
> I don't see why this is helpful. Could you explain why
> _RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python version.
I suppose it's so that people who only override flush() automatically get
Hey Antoine,
Thanks for the clarification!
I see that the C implementation matches the Python implementation but I
don't see how the semantics of either are useful in this case.
If a subclass implements flush then, as you say, it must also implement
close and call flush itself before calling
Hi!
sweetapp.com> writes:
>
> class _RawIOBase(_FileIO):
FileIO is a subclass of _RawIOBase, not the reverse:
>>> issubclass(_io._RawIOBase, _io.FileIO)
False
>>> issubclass(_io.FileIO, _io._RawIOBase)
True
I do understand your surprise, but the Python implementation of IOBase.close()
in _pyi
Hey,
I noticed that the call pattern of the C-implemented io libraries is as
follows (translating from C to Python):
class _FileIO(object):
def flush(self):
if self.__IOBase_closed:
raise ...
def close(self):
self.flush()
self.__IOBase_closed = True
class _RawIOBase(_FileI
16 matches
Mail list logo
