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 twouters
Recipients benjamin.peterson, ezio.melotti, pitrou, terry.reedy, twouters, vstinner
Date 2013-03-15.22:34:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1363386875.81.0.595318339811.issue17411@psf.upfronthosting.co.za>
In-reply-to
Content
Unfortunately there is no "release mode". There's Py_DEBUG mode, and the absence of Py_DEBUG. And there's NDEBUG, and the absence of NDEBUG, which controls the assert macro. Py_DEBUG unsets NDEBUG, but *not* setting Py_DEBUG doesn't *set* NDEBUG (nor should it.)

In the Google build environment, where we occasionally embed Python and also build extensions that use Python and Python itself in slightly different ways, we have build modes that don't set Py_DEBUG but don't set NDEBUG -- so we keep the asserts, but don't set Py_DEBUG (which would change the ABI.) I suggest that this is a valid expectation :) If something is used in assert statements (and _PyUnicode_CheckConsistency is, quite a lot) it needs to be defined whenever NDEBUG is not defined, not just when Py_DEBUG is defined. The patch makes it a macro that calls PyUnicode_Check() in that case, because that's what unicodeobject.c itself does.

In the case of obmalloc, the asserts are calling functions that are only defined when PYMALLOC_DEBUG is set, so it seems obvious that that's the guard that should surround their use.
History
Date User Action Args
2013-03-15 22:34:35twouterssetrecipients: + twouters, terry.reedy, pitrou, vstinner, benjamin.peterson, ezio.melotti
2013-03-15 22:34:35twouterssetmessageid: <1363386875.81.0.595318339811.issue17411@psf.upfronthosting.co.za>
2013-03-15 22:34:35twouterslinkissue17411 messages
2013-03-15 22:34:35twouterscreate