Martin v. Löwis <mar...@v.loewis.de> added the comment: > Can anyone point me at a test that failed in this case?
See issue 1350409 (and subsequently #1167262 and #1311784). Python fails to start when assertions are turned on (haven't tested for VS 2008, though). If you were looking for a test case that fails specifically - there might none. However, try Amaury's example. > On the broader point, it could be argued that if it is the apps > responsibility to re-enable assertions, it is also the apps > responsibility to disable them in the first place. Ideally, assertions should be enabled in debug builds, and disabled in release builds, and there should be no runtime configuration. Unfortunately, Microsoft chose to add bogus assertions, so this general rule is useless within the context of MSC. (it's not just that the signal issue is a standards violation. Assuming that _close apparently follows POSIX close, it should always set errno to EBADF for a double-close, rather than raising an assertion. It is conforming in release mode, but loses conformance in debug mode) > From > a pragmatic POV, if we know the MS crt asserts on certain constants > signal numbers, can't we just avoid passing those numbers? It's the other way 'round: it rejects all but a list of known signals. Still, it would be possible to hack around - one such hack is currently implemented. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4804> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
