Message113330
| Author |
pitrou |
| Recipients |
georg.brandl, mkc, pitrou, terry.reedy |
| Date |
2010年08月08日.21:40:35 |
| SpamBayes Score |
1.7350001e-07 |
| Marked as misclassified |
No |
| Message-id |
<1281303637.82.0.00468260835248.issue5319@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I've committed the py3k fix in r83854 (3.1 in r83855).
As for 2.6/2.7, I've finally diagnosed the problem: 2.6 and upwards use PyErr_Print() in the file destructor, but the sys.stderr and sys.excepthook objects are already None at that time (because of interpreter shutdown). Therefore the error can't be printed out.
2.5 and earlier used a direct fprintf() of the errno code to stderr.
I propose to ignore the 2.6/2.7 issue of the error not being printed properly, since it only happens at shutdown with a misbehaving stdout, which is not very common.
As for the issue of the stdout error not being reported in the process return code, this would be possible in 3.x, although it would involve changing the signature of Py_Finalize() to include a return status (it currently returns void). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2010年08月08日 21:40:37 | pitrou | set | recipients:
+ pitrou, georg.brandl, terry.reedy, mkc |
| 2010年08月08日 21:40:37 | pitrou | set | messageid: <1281303637.82.0.00468260835248.issue5319@psf.upfronthosting.co.za> |
| 2010年08月08日 21:40:35 | pitrou | link | issue5319 messages |
| 2010年08月08日 21:40:35 | pitrou | create |
|