bpo-38007: Added ts_ prefix to PyType_Spec struct members by LeslieGerman · Pull Request #15644 · python/cpython

the-knights-who-say-ni

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Our records indicate we have not received your CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for your contribution, we look forward to reviewing it!

So the conflicting "slots" member was renamed to "ts_slots"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a slight difference though, _heaptypeobject is not API whereas PyType_FromSpec is. Unless there is a really good reason to break compatibility (which usually happens when a CPython bug is found), the API shouldn't change. Without any more context on why this change is needed, it's unclear if this is the proper fix.

Unless there is a really good reason to break compatibility (which usually happens when a CPython bug is found), the API shouldn't change.

@eduardo-elizondo , please note that this change does NOT break binary compatibility. Any built library or application which used PyType_Spec and/or its members, will still work correctly, since the memory layout of PyType_Spec remained the same.

If any new version is created for such library/application, usually it is recompiled anyway, then the renaming can be applied in the client code - if those members were in use, at all.
So I don't see any dangerous impact.

Idea about a regression test

So that "slots" or "signals" is not introduced again in the headers as an entity name.

Add a test, which compiles all CPython headers by mimicing Qt headers have included.
Add the -Dslots= -Dsignals= to compiler options.

If there are no compiler errors, the test passes, otherwise fails.

Possible implementation

Make a list of the CPython headers.
Create a temporary C file with content:

#define slots
#define signals

#include "cpython_header_1.h"
#include "cpython_header_2.h"
...
#include "cpython_header_N.h"

static int something_dummy_so_that_object_file_is_not_empty;

Compile it
If compiles without error => the test passes, fails otherwise.

I found an "official" Qt solution for this whole issue, the QT_NO_SIGNALS_SLOTS_KEYWORDS and QT_NO_KEYWORDS macros.
See more detail here.

So this PR is not necessary anymore, so I close it.