Message101828
| Author | michael.foord |
|---|---|
| Recipients | Technologov, andersjm, christian.heimes, kap4020, loewis, michael.foord, nnorwitz, tebeka, tim.peters, trent |
| Date | 2010-03-27.13:52:12 |
| SpamBayes Score | 0.00058073 |
| Marked as misclassified | No |
| Message-id | <1269697934.79.0.521990270946.issue1220212@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
To make it clear, even though it would be incomplete, a partial implementation of os.kill(...) for Windows would be very useful and provide some level of compatibility with applications that use os.kill (so even if os.kill(...) duplicates functionality in other modules - although that was disputed - it should be provided for compatibility reasons). An implementation similar to the IronPython one is probably the best that can be managed and would still be useful: accepting only signal.SIGINT and signal.SIGBREAK and first trying Kernel32.GenerateConsoleCtrlEvent, falling back to killing the process. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2010-03-27 13:52:15 | michael.foord | set | recipients: + michael.foord, tim.peters, loewis, nnorwitz, tebeka, andersjm, christian.heimes, kap4020, Technologov, trent |
| 2010-03-27 13:52:14 | michael.foord | set | messageid: <1269697934.79.0.521990270946.issue1220212@psf.upfronthosting.co.za> |
| 2010-03-27 13:52:12 | michael.foord | link | issue1220212 messages |
| 2010-03-27 13:52:12 | michael.foord | create | |