Petr Viktorin

Please do not convert the `T_*` macros (`T_SHORT` etc.), though. I'm making bigger changes in that area.

I am not convinced. I'm wary of making error messages depend on the str representation of a function; that would prevent us from changing it later. I'm wary of "%S"...

I like [PR 14890](https://github.com/python/cpython/pull/14890) better. I like the separation of representation for error messages (where it's clearer that this is a callable) and for \_\_str__. Also, changing the \_\_str__ of...

My bad, I didn't publish the comments. They should be there now.

With this change, CPython no longer uses PyEval_GetFuncName/PyEval_GetFuncDesc internally. Shall we deprecate/discourage them? Shall we expose PyObject_FunctionStr publicly?

Before deprecating them, we should provide a good replacement for the use case they served. It could mean exposing PyObject_FunctionStr, which would mean documenting it, and deciding what kind of...

Does this solve an issue? We don't generally do style-only changes.

Žádný spěch, vydrží to i nějaký měsíc :)

Today I noticed the style guide says [macros should have the `Py_` prefix](https://peps.python.org/pep-0007/#naming-conventions), not `PY_`. A minor point, but since this is renaming a bunch of macros, I'll switch to...

> The PY_T_*, PY_READONLY and PY_AUDIT_READ macros are added to the stable API manifest. This is just a clerical change, really -- Stable ABI extensions in the wild use structmember.h,...