[issue20074] open() of read-write non-seekable streams broken
pavlix added the comment: > A non-seekable read/write stream doesn't really make sense (think about it). How does it help the issue to ask the reporter to "think" when the have already provided an easily reproducable use case? > What purpose does that constraint serve? Is there any reason it shouldn't be > relaxed? Can we *please* get an answer to this question? > Antoine already answered that question: it does not make sense to have a > single stream that is open for *update* if it is not seekable. How does this statement, already refuted by the reporter, bring us any closer to the answer to the question above? Was this an arbitrary decision of someone who didn't think about character devices? Or is there any particular reason to prevent the use of "r+", "w+", "rb+" and "wb+" with readable-writable character devices? -- nosy: +pavlix ___ Python tracker <https://bugs.python.org/issue20074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20074] open() of read-write non-seekable streams broken
pavlix added the comment: Okay, let me help the situation a bit. The “workaround” of using `buffering=0` works perfect with `rb+` and `wb+` and I'm pretty sure I used this in the past. I don't know how well this is documented. I would usually need to disable buffering for any real-time binary communication anyway, so for me the workaround is reasonable. As for buffered I/O and `r+`/`b+` where you cannot disable buffering, I don't know. It would be useful to have a good reason behind the limitation of Python and have it documented, or have the limitation lifted if there's none, so this issue can be closed. Could anyone please explain why binary streams default to buffered I/O in the first place? Does it make any sense or it's just historical cruft? -- ___ Python tracker <https://bugs.python.org/issue20074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
