@@ -295,10 +295,10 @@ PyAPI_FUNC(PyObject *) PyType_GetDict(PyTypeObject *);
295295
296296PyAPI_FUNC (int ) PyObject_Print (PyObject * , FILE * , int );
297297PyAPI_FUNC (void ) _Py_BreakPoint (void );
298- PyAPI_FUNC (void ) PyObject_Dump (PyObject * );
298+ PyAPI_FUNC (void ) PyUnstable_Object_Dump (PyObject * );
299299
300300// Alias for backward compatibility
301- #define _PyObject_Dump PyObject_Dump
301+ #define _PyObject_Dump PyUnstable_Object_Dump
302302
303303PyAPI_FUNC (PyObject * ) _PyObject_GetAttrId (PyObject * , _Py_Identifier * );
304304
@@ -390,10 +390,11 @@ PyAPI_FUNC(PyObject *) _PyObject_FunctionStr(PyObject *);
390390 process with a message on stderr if the given condition fails to hold,
391391 but compile away to nothing if NDEBUG is defined.
392392
393- However, before aborting, Python will also try to call PyObject_Dump() on
394- the given object. This may be of use when investigating bugs in which a
395- particular object is corrupt (e.g. buggy a tp_visit method in an extension
396- module breaking the garbage collector), to help locate the broken objects.
393+ However, before aborting, Python will also try to call
394+ PyUnstable_Object_Dump() on the given object. This may be of use when
395+ investigating bugs in which a particular object is corrupt (e.g. buggy a
396+ tp_visit method in an extension module breaking the garbage collector), to
397+ help locate the broken objects.
397398
398399 The WITH_MSG variant allows you to supply an additional message that Python
399400 will attempt to print to stderr, after the object dump. */
0 commit comments