Armin Rigo <[EMAIL PROTECTED]> added the comment: 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.) __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1798> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
