Message255933
| Author |
martin.panter |
| Recipients |
Daniel.Gonzalez, bhuvan, eric.araujo, ezio.melotti, ggenellina, jaraco, martin.panter, mdomingues, taleinat |
| Date |
2015年12月05日.08:12:39 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1449303160.69.0.718217963729.issue1927@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Here is an updated patch for Python 3.
I did not remove the "lost sys.stderr" check I mentioned earlier, because the implementation still needs it to call flush().
Changes compared to Michael’s patch:
* Added a test for input() using a pseudoterminal and subprocess.Popen
* Write to the passed-in sys_stdout parameter, not the global stdout
* Continue to call fflush(stderr), to avoid regressions with buffered stderr messages
* Updated /Parser/pgenmain.c to use sys_stdout
I also had to update test_cmd_line_script, which expected the prompt to be on stderr. This made me wonder if it is a good idea to change where the interpreter prompt (>>>) goes in a bugfix release. AFAIK it is not documented, and it could potentially break other things that use the interactive interpreter. What do people think? A way to avoid this might be to pass stderr as the sys_stdout parameter.
Also, it would be awesome if someone could try my new test_builtins test case on BSD or OS X. I only tested it with Linux. The last time I messed with pseudoterminals like this I caused the tests to hang on BSD buildbots. |
|