Needs care because I haven't yet checked *every* place this is called.

But the bulk of places it's called are in _PyUnicode_CheckConsistency
and its friends -- where if NDEBUG we don't want to even call them.
So, pending confirmation of that (and perhaps migrating any exceptions
to a slightly different API), this should be just fine.

Indeed we could go further and not even check _PyObject_ASSERTIONS
here.  Probably should use a different name from "assert" then, though.

---

There's a warning when doing a release build:

Objects/unicodeobject.c: In function ‘_PyUnicode_CheckConsistency’:
Objects/unicodeobject.c:507:15: warning: variable ‘data’ set but not used [-Wunused-but-set-variable]
         void *data;
               ^~~~

That's with:

$ gcc --version
gcc (Debian 8.3.0-6) 8.3.0

Introduced here:

commit 0fc91ee
Author: Victor Stinner <vstinner@redhat.com>
Date:   Fri Apr 12 21:51:34 2019 +0200

    bpo-36389: Add _PyObject_CheckConsistency() function (pythonGH-12803)

    Add a new _PyObject_CheckConsistency() function which can be used to
    help debugging. The function is available in release mode.

    Add a 'check_content' parameter to _PyDict_CheckConsistency().

 Include/cpython/object.h         |  15 ++++++
 Include/internal/pycore_object.h |   4 ++
 Objects/dictobject.c             | 118 +++++++++++++++++++++----------------------
 Objects/object.c                 |  31 +++++++++++-
 Objects/typeobject.c             |  11 ++--
 Objects/unicodeobject.c          |  93 ++++++++++++++++------------------
 6 files changed, 158 insertions(+), 114 deletions(-)