[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2020-04-08 Thread Daniel Holth
Change by Daniel Holth : -- nosy: +dholth ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2019-03-23 Thread Gregory Szorc
Gregory Szorc added the comment: It's also worth noting that if the wrapped stream close() cascading behavior should be configurable, then many additional types in the standard library need a constructor argument to control this behavior. e.g. io.TextIOWrapper, io.BufferedReader, io.Buffered

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2019-03-23 Thread Gregory Szorc
Gregory Szorc added the comment: Thank you for the detailed reply, Josh. I generally agree with what you are saying. However, I have some follow-ups. In your answer to #2, you seem to distinguish between an "fd" (implying POSIX file descriptor) and "Python layers" (implying a file object). I

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2019-02-26 Thread Josh Rosenberg
Josh Rosenberg added the comment: The general rule of thumb is to have the API behave as if no wrapping is occurring. The outermost layer should still adhere to the documented API requirements, so both flush and close should cascade (flush says it flushes the "buffers" plural; all user mode

[issue36129] io documentation unclear about flush() and close() semantics for wrapped streams

2019-02-26 Thread Gregory Szorc
New submission from Gregory Szorc : As part of implementing io.RawIOBase/io.BufferedIOBase compatible stream types for python-zstandard, I became confused about the expected behavior of flush() and close() when a stream is wrapping another stream. The documentation doesn't lay out explicitly