[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Martin Panter added the comment: Also stumbled upon Issue 1705393: confusion with select() and buffered files -- ___ Python tracker ___

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Martin Panter added the comment: Where would you draw the line though? At one extreme, BufferedWriter is a wrapper, but if you removed BufferedWriter.fileno() it would break all the code that does with open(os.devnull, "wb") as null: proc = subprocess.Popen(..., stdout=null) Would you

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Jonas H. added the comment: I just hit this too. I'd say remove the fileno() method from wrapper objects like GzipFile. I'm happy to submit a patch. -- nosy: +jonash ___ Python tracker

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +benjamin.peterson, pitrou, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24358 ___

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Josh Rosenberg added the comment: Blech, typo earlier since they produce the *compressed* data (likely useless) when read as subprocess stdin. Context should make it obvious, but trying to be clear. -- ___ Python tracker rep...@bugs.python.org

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Josh Rosenberg added the comment: Apparently similar issue occurs when tarfile assumes a GzipFile can have its fileno() fstat-ed (see #22468). An awful lot of libraries seem to assume that fileno() will provide useful information about the data you'd read from the file-like object itself, but

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

New submission from Josh Rosenberg: subprocess, when accepting objects for stdin, stdout, and stderr, assumes that possessing a .fileno() means it's a legitimate object for use with the forked process; that the file descriptor is interchangeable with the object itself. But gzip, bz2 and lzma

[issue24358] Should compression file-like objects provide .fileno(), misleading subprocess?

Martin Panter added the comment: Also related: Issue 23740, where the HTTP client assumes it can use stat() on the fileno() to determine the Content-Length. Providing fileno() on file wrapper objects like GzipFile is certainly not necessary, but it could be useful. For instance in the tarfile