This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author arigo
Recipients amaury.forgeotdarc, arigo, fijal, loewis, theller
Date 2008-05-23.15:57:18
SpamBayes Score 0.015223444
Marked as misclassified No
Message-id <>
I'm in favor of keeping set_errno().  Not only is it more like C, but
it's also future-proof against a user that will end up really needing
the feature.  If we go for always setting errno to zero, we cannot
change that later any more, because everybody's code will rely on it. 
(An example of possible usage of set_errno(): the user might need to
save and restore the value around a subfunction call that may call more
C function via ctypes.)

I personally don't care if this means a few percents of performance
loss; I don't see how ctypes can be performance-critical in the first
place given its huge overhead compared to e.g. rewriting the code in C.

I imagine that the same approach could work with GetLastError() on
Windows.  (But is there a SetLastError() on Windows?)

Using the native errno instead of a custom TLS value is bad because a
lot of things can occur; for example, adding debugging prints or a pdb
breakpoint between the function return and the call to get_errno() is
very likely to end up overwriting the C-level errno value.  For all I
know, on some platforms errno could even be overwritten by the calls to
the unlock/lock operation that CPython does at regular intervals in
order to let other threads run.  (For example I can easily imagine that
GetLastError() is overridden by the lock/unlock operations on Windows.)
Date User Action Args
2008-05-23 15:57:22arigosetspambayes_score: 0.0152234 -> 0.015223444
recipients: + arigo, loewis, theller, amaury.forgeotdarc, fijal
2008-05-23 15:57:21arigosetspambayes_score: 0.0152234 -> 0.0152234
messageid: <>
2008-05-23 15:57:21arigolinkissue1798 messages
2008-05-23 15:57:18arigocreate