On Sun, Jan 24, 2021 at 9:53 AM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
On 2021-01-25 at 00:29:41 +1100,
Steven D'Aprano <steve@pearwood.info> wrote:

> On Sat, Jan 23, 2021 at 03:24:12PM +0000, Barry Scott wrote:
> > First problem I see is that the file may be a pipe and then you will block
> > until you have enough data to do the auto detect.
> Can you use `open('filename')` to read a pipe?

Yes.  Named pipes are files, at least on POSIX.

And no.  Unnamed pipes are identified by OS-level file descriptors, so
you can't open them with open('filename'),

The `open` function takes either a file path as a string, or a file descriptor as an integer. So you can use `open` to read an unnamed pipe or a socket.

> Is blocking a problem in practice? If you try to open a network file,
> that could block too, if there are network issues. And since you're
> likely to follow the open with a read, the read is likely to block. So
> over all I don't think that blocking is an issue.

If open blocks too many bytes, then my application never gets to respond
unless enough data comes through the pipe.

It's possible to do a `f.read(1)` on a file opened in text mode. If the first two bytes of the file are 0xC2 0x99, that's either ™ if the file is UTF-8, or 슙 if the file is UTF-16BE, or 駂 if the file is UTF-16LE. And `f.read(1)` needs to pick one of those and return it immediately. It can't wait for more information. The contract of `read` is "Read from underlying buffer until we have n characters or we hit EOF." A call to `read(1)` cannot keep blocking after the first character was received to decide what encoding to decode it as; that would be backwards incompatible, and it might block forever if the sender only sends one character before waiting for a response.