Non-namespaced identifiers

[encukou]

The headers define a number of identifiers that don't start with Py (or _Py), potentially clashing with other code.

• slot function typedefs like destructor or setter
• calling convention names like METH_VARARGS
• non-typedef'd structs, like struct _object
• configure cruft like HAVE_STRFTIME or SIZEOF_SIZE_T
• and more

Relatedly, header names should probably also be namespaced (or hidden in a subdirectory, expecially if users aren't supposed to include them directly)

[gvanrossum]

All of this can be solved incrementally, right? Just slap a PY_ prefix on various things? Agreed that if we're designing a new API we should take care of this. Honestly my memory is fuzzy on why we used the Py prefix for typedefs but not for struct names, for example. (I can see why originally we used it only for functions, since linker namespaces are much more global than included files.)

[encukou]

I don't think we should rename struct _object, it's not a problem in practice. Any new API (or subset) should not include it of course.

Automation to catch mistakes might help.

[encukou]

(Somewhat related: Qt infamously breaks Python API by defining the macro slots, which we use for a struct member. Not really our problem to fix, but, once we allow anonymous unions in headers we can fix even unfortunate member names incrementally.)

[vstinner]

I don't think we should rename struct _object, it's not a problem in practice

I was always annoyed that the structure is not simply called PyObject as the type.

Why is the structure of the PyInterpreterState called... _is? Who has to save some letters for this name?

In practice, the structure name are never used. So we can just fix them, no?

[vstinner]

configure cruft like HAVE_STRFTIME or SIZEOF_SIZE_T

That's a hard problem since most names are generated by configure, and changing configure is not easy.

Maybe Python.h should not include pyconfig.h, but a new header which only exposes Py_ names needed to declare the C API. Or pyconfig.h can be fixed, and a new "full header" can be moved to the internal C API.

[vstinner]

slot function typedefs like destructor or setter

Maybe we can introduce new Py_ names and deprecate the old ones. Removing them right now would break many C extensions.

For example, it's common to have to cast a function to (PyCFunction) to ignore compiler warnings about the number of arguments. I recently added _PyCFunction_CAST() to handle that. Maybe this cast should be made public. I don't know. This cast can cause some legit bugs break CFI checks, when a function has only 1 argument, whereas the ABI requires 2 arguments. So it should be used carefully (I tried to implement that in _PyCFunction_CAST()).

[erlend-aasland]

configure cruft like HAVE_STRFTIME or SIZEOF_SIZE_T

That's a hard problem since most names are generated by configure, and changing configure is not easy.

We can easily define autoconf macros that wrap AC_DEFINE and AH_TEMPLATE and use those throughout .ac file. I'd be tempted to call it low-hanging fruit :)

[gvanrossum]

@erlend-aasland

We can easily define autoconf macros that wrap AC_DEFINE and AH_TEMPLATE and use those throughout .ac file. I'd be tempted to call it low-hanging fruit :)

So maybe just create a cpython issue + PR for this (linking back here)?

[erlend-aasland]

So maybe just create a cpython issue + PR for this (linking back here)?

Thanks for the ping. Yes, it's on my list; I just haven't found the time to do it yet. I'll create the issue right away, though.

UPDATE: I created python/cpython#105813

[vstinner]

See my comment #43 (comment) about E_EOF constant of errcode.h which is used by public PyRun_InteractiveOneObject() function: the doc suggests including <errcode.h> explicitly.