Re: [Python-Dev] PyObject_REPR()

If PyObject_REPR changes or gets renamed in Py2.5, I suggest modifying the implementation so that it returns a newly allocated C pointer rather one embedded in an inaccessible (unfreeable) PyStringObject. Roughly: r = PyObject_Repr(o); if (r == NULL) return NULL; s1 = PyObject_AS_STRING(r); s2 = strcpy(s1); Py_DECREF(r); return s2; The benefits are: * it won't throw-off leak checking (no Python objects get leaked) * the leak is slightly smaller (only the allocated string) * if the caller cares about memory, they have the option of freeing the returned pointer * error-checking is still possible. Neal Norwitz wrote:

Ok, then how about prefixing with _, adding a comment saying in big, bold letters: FOR DEBUGGING PURPOSES ONLY, THIS LEAKS, and only defining in a debug build?

n -- On 4/11/06, Jeremy Hylton wrote:

...

It's intended as an internal debugging API. I find it very convenient for adding with a printf() here and there, which is how it got added long ago. It should really have a comment mentioning that it leaks the repr object, and starting with an _ wouldn't be bad either.

Jeremy

On 4/11/06, Neal Norwitz wrote:

...

On 4/11/06, Raymond Hettinger wrote:

...

...

It strikes me that it should not be used, or maybe renamed to _PyObject_REPR. Should removing or renaming it be done in 2.5 or in Py3K?

Since it is intrinsically buggy, I would support removal in Py2.5

+1 on removal. Google only turned up a handleful of uses that I saw.

n _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu

---

Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/rhettinger%40ewtllc.com