Message189996
| Author |
tim.golden |
| Recipients |
David.Gilman, loewis, tim.golden |
| Date |
2013年05月25日.20:30:37 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1369513838.33.0.115378342996.issue18040@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
My initial reaction is that, whether the 2.7 behaviour is faulty or not, I can't reproduce the "correct" behaviour on any version of Windows going back to 2.4. Take the attached Python file issue18040.py and run "c:\pythonxx\python.exe -i issue18040.py" for any version of Python from 2.4 to 3.4. At the interpreter prompt, pressing Ctrl-C produces "Keyboard Interrupt" consistently (except for the few times it exits the interpreter which is the problem fixed in issue1677).
Note that this applies to pressing Ctrl-C *at the interpreter prompt* (while the running code is the function my_fgets in parser/myreadline.c). Pressing Ctrl-C in other circumstances, eg in the middle of a long-running os.walk or a time.sleep, invokes the signal handler as expected.
I don't know if the handler *should* be invoked at the interpreter prompt. I recognise that it does so under Linux, but are there any circumstances where that would actually be useful? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年05月25日 20:30:38 | tim.golden | set | recipients:
+ tim.golden, loewis, David.Gilman |
| 2013年05月25日 20:30:38 | tim.golden | set | messageid: <1369513838.33.0.115378342996.issue18040@psf.upfronthosting.co.za> |
| 2013年05月25日 20:30:38 | tim.golden | link | issue18040 messages |
| 2013年05月25日 20:30:37 | tim.golden | create |
|