New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
restore accepting detached stdin in fileinput binary mode #66898
Comments
The patch for Issue bpo-21075: "fileinput.FileInput now reads bytes from standard stream if binary mode is specified" broke code that used I've attached the patch that makes FileInput to accept detached sys.stdin |
The code sys.stdin = sys.stdin.detach() is incorrect because sys.stdin should be text stream, but detach() returns binary stream. |
It is incorrect that sys.stdin is *always* a text stream. It often is, There are cases when it is not e.g., $ tar zcf - stuff | gpg -e | ssh user@server 'cat - > stuff.tar.gz.gpg' tar's stdout is *not* a text stream. If any of the steps are implemented in Python then it is useful to Any script written before Python 3.4.1 (bpo-21075) that used FileInput binary mode A bugfix release should not break working code. |
This is not related to Python. Terms "character", "string", "text", "file" can
Correct solution in this case would be to use the workaround "sys.stdin = |
I use Python terminology (text - Unicode string, binary data - bytes). Though text vs. binary data distinction is language independent ( Python can be used to implement It is very simple actually: text -> encode <character encoding> -> bytes In most cases text should be human readable. It doesn't make sense to encode/decode input/output of gpg-like utilities using a character encoding. *Therefore* the notion of The lines produced by FileInput are often (after optional processing) It introduces a nice symmetry: text FileInput mode -> text streams By design, FileInput treats stdin as any other file. It sys.stdout is used outside of FileInput therefore no changes in
Do you mean every Python 3 version before Python 3.4.1? Correct solution is to avoid blaming users |
I actually agree that this should be applied not only for backward compatibility reasons, but because it is better duck typing. It unfortunately leaves code still having to potentially deal with "if python version is 3.4.1 or 3.4.2", but there is nothing that can be done about that. |
New changeset ded1336bff49 by R David Murray in branch '3.5': New changeset 688d32cdbc0c by R David Murray in branch 'default': |
Hopefully 'better late than never' applies to this. Sigh. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: