[issue20074] open() of read-write non-seekable streams broken

Ken Teh added the comment: It works on macos but not on linux, ie, I have a usb-serial dongle connected to a serial device (a CAMAC controller), and I do an os.open() with 'wb+', followed by a io.fdopen(). I can talk to my device on macos BigSur 11.2, buffered, but not on Linux which throws

[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

[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

[issue20074] open() of read-write non-seekable streams broken

cagney added the comment: Another example is PTY: Python 2.7.15 (default, Oct 15 2018, 15:24:06) [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> pty, tty = os.openpty() >>> print(pty, tty) (3, 4) >>> imp

[issue20074] open() of read-write non-seekable streams broken

Martin Panter added the comment: Currently, the documentation for TextIOWrapper says it is “a buffered text stream over a BufferedIOBase binary stream.” If passing a RawIOBase (buffering=0) file works, that seems like an undocumented accident. This is also explicitly disallowed with open(). “P

[issue20074] open() of read-write non-seekable streams broken

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue20074] open() of read-write non-seekable streams broken

R. David Murray added the comment: 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. The fact C conflates "update" with "both read and write" can be seen as a design bug in C :) The remaining question might

[issue20074] open() of read-write non-seekable streams broken

Dolda2000 added the comment: >So the question is, is the *design* of the IO module that '+' requires a >seekable stream the best behavior, or can that constraint be relaxed? What purpose does that constraint serve? Is there any reason it shouldn't be relaxed? It seems to work quite well witho

[issue20074] open() of read-write non-seekable streams broken

Antoine Pitrou added the comment: > Having buffering doesn't make the stream seekable. So the question > is, is the *design* of the IO module that '+' requires a seekable > stream the best behavior, or can that constraint be relaxed? A non-seekable read/write stream doesn't really make sense (t

[issue20074] open() of read-write non-seekable streams broken

R. David Murray added the comment: Having buffering doesn't make the stream seekable. So the question is, is the *design* of the IO module that '+' requires a seekable stream the best behavior, or can that constraint be relaxed? You have to keep in mind that the IO module is a bunch of build

[issue20074] open() of read-write non-seekable streams broken

Roundup Robot added the comment: New changeset 100f632d4306 by R David Murray in branch '3.3': #18116: backport fix to 3.3 since real-world failure mode demonstrated. http://hg.python.org/cpython/rev/100f632d4306 -- nosy: +python-dev ___ Python tracke

[issue20074] open() of read-write non-seekable streams broken

Dolda2000 added the comment: Oh sorry, my bad. I messed up. :) Given that that works, though, why can't open() handle opening /dev/tty directly in text mode? Clearly, TextIOWrapper can handle the necessary buffering without the stream having to be seekable. -- ___

[issue20074] open() of read-write non-seekable streams broken

Serhiy Storchaka added the comment: > >>> import io > >>> io.TextIOWrapper(open("/dev/tty", "rb+")) > > Traceback (most recent call last): > File "", line 1, in > io.UnsupportedOperation: File or stream is not seekable. buffering=0 -- ___ Python

[issue20074] open() of read-write non-seekable streams broken

Dolda2000 added the comment: Python 3.3.3 (default, Dec 8 2013, 14:51:59) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import io >>> io.TextIOWrapper(open("/dev/tty", "rb+")) Traceback (most recent call last): File "", line 1, in io.Unsuppor

[issue20074] open() of read-write non-seekable streams broken

Serhiy Storchaka added the comment: > It's nice that that's at least possible, but I, for one, would still consider > it a bug that it isn't possible to open it in text mode. >>> io.TextIOWrapper(open("/dev/tty", "r+b", buffering=0)) <_io.TextIOWrapper name='/dev/tty' encoding='UTF-8'> > Just

[issue20074] open() of read-write non-seekable streams broken

Dolda2000 added the comment: Just to demonstrate failure of getpass, by the way: $ cat >/tmp/pwtest.py import getpass print(getpass.getpass()) $ python3 /tmp/pwtest.py print(getpass.getpass()) File "/usr/lib/python3.3/getpass.py", line 83, in unix_getpass passwd = fallback_getpass(pro

[issue20074] open() of read-write non-seekable streams broken

Dolda2000 added the comment: >I don't think getpass will fail, since it uses os.open, not open. It also uses fdopen() on the resulting file descriptor, however, which has the same problem. >Use unbuffered binary file. It's nice that that's at least possible, but I, for one, would still consid

[issue20074] open() of read-write non-seekable streams broken

Serhiy Storchaka added the comment: Use unbuffered binary file. >>> open("/dev/tty", "r+b", buffering=0) <_io.FileIO name='/dev/tty' mode='rb+'> -- nosy: +serhiy.storchaka ___ Python tracker __

[issue20074] open() of read-write non-seekable streams broken

R. David Murray added the comment: I don't think getpass will fail, since it uses os.open, not open. Presumably you can work around the problem by opening the stream twice: once for reading and once for writing. I'll leave it to Antoine to say whether or not that is in fact the expected solut

[issue20074] open() of read-write non-seekable streams broken

New submission from Dolda2000: It seems open() is slightly broken in Python 3, in that one cannot open non-seekable files in read-write mode. One such common use is open("/dev/tty", "r+") for interacting directly with the controlling TTY regardless of standard stream redirections. Note that th