Thomas Wouters <thomas at python.org> wrote: > Do you test against pydebug builds of Python, or otherwise a build that > actually enables asserts? Yes, I do (and much more than that): http://hg.python.org/features/cdecimal/file/40917e4b51aa/Modules/_decimal/python/runall-memorydebugger.sh http://hg.python.org/features/cdecimal/file/40917e4b51aa/Modules/_decimal/python/runall.bat It's automated, so it's not a big deal. You get 100% coverage, with and without threads, all machine configurations, pydebug, refleaks, release build and release build with Valgrind. The version on PyPI has had the same tests for a long time (i.e. also before I became involved with core development). > Because I suspect most people don't, so they don't trigger the assert. > Python is normally (that is, a release build on Windows or a regular, > non-pydebug build on the rest) built without asserts. Asserts are > disabled by the NDEBUG symbol, which Python passes for regular builds. If many C-extension authors don't know the benefits of --with-pydebug and the consensus here is to protect these authors and their users, then of course I agree with the exception approach for a (now hypothetical) API change. I would have some comments about valid uses of explicit aborts in a library that essentially perform the same function as compiling said library with -D_FORTIFY_SOURCE=2 and -ftrapv (i.e. crash when an external program violates a function contract), but I suspect that would be OT now. Stefan Krah
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4