bpo-38007: Added ts_ prefix to PyType_Spec struct members

[LeslieGerman]

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

https://bugs.python.org/issue38007

[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!

[eduardo-elizondo]

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.

[LeslieGerman]

Without any more context on why this change is needed

@eduardo-elizondo , for the same reason https://bugs.python.org/issue1086854 was opened. The "slots" member causes compilation errors.
Please see https://bugs.python.org/msg350977

To decrease compatibility issues we might rename only the "slots" member.

[LeslieGerman]

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.

[LeslieGerman]

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

1. Make a list of the CPython headers.
2. 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;

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

[LeslieGerman]

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.

[eduardo-elizondo]

Cool!