In Feb 20, 2006, in commit https://github.com/python/cpython/commit/c255c7bef7621596869f56d887ac3ccd5b536708 the bug https://bugs.python.org/issue1086854 had been fixed.

In Dec 3, 2010, in commit https://github.com/python/cpython/commit/4d0d471a8031de90a2b1ce99c4ac4780e60b3bc9 basically the same issue has been introduced again, because it added a "slots" member to the added PyType_Spec struct.

The proposed solution is the same like in the earlier commit, which is explained in https://bugs.python.org/msg23759 :
protect PyType_Spec struct members with prefix:
ts_name, ts_doc, ts_basicsize, ts_itemsize, ts_flags, ts_slots

My initial thought is similar to that of Michael Hudson in msg23757, that Python should not be hostage to foreign code processors.  I also note that the 2010 patch is by Martin Loewis, who was part of the 2006 discussion, and that the 2010 patch was about the stable public ABI, which should not be changed.  But I am not familiar with C details at all.

This is a major breaking change. It may need changing the Python version to 4.0.

I suggest you to not use global macros without prefixes and undefine the conflicting one before using the Python C API.

I don't understand this issue, it mostly contains reference to other bugs. Can someone please try to elaborate the issue?

"Regression: name of PyType_Spec::slots conflicts with Qt macro"

What is "::slots"? Is it C++ syntax?

I don't understand how "slots" name can be an issue: it's not a global variable, but a structure member name.

Yes, even as a struct member name (at least in the definition), the C preprocessor will substitute a macro. It sounds like Qt defines a macro "slots", and so the definition of the struct will be broken.

Unfortunately, this would be a more significant change than removing the deprecated tp_print field, which we eventually decided not to do because of the compatibility impact. So I can confidently say we won't be able to do this one either.

(You might also argue that Qt should be the ones fixing their namespacing.)

Some history and explanation of this problem:

- Qt extends C++ with the following keywords:
  "slots", "signals", "emit"
- This extension is compiled with a Meta-Object-Compiler (MOC) into standard C++.
- Since code using Qt extensions (i.e. headers) generally used "mixed" with standard C++ code, "standard" compiler must be able to compile the Qt specific part, too
  -> the extension keywords are declared as empty macros (i.e. #define slots)

The consequence is that if Qt-based headers are used together with any 3rd party headers, the 3rd party code cannot contain the extension keywords (slots, signals, emit) as C/C++ tokens, because the preprocessor will "delete" them as a result of macro expansion, since the keywords are defined as empty macros.
->
The code won't compile because of syntax errors.

This caused bug https://bugs.python.org/issue1086854 , which was fixed in https://github.com/python/cpython/commit/c255c7bef7621596869f56d887ac3ccd5b536708

The fix renamed the "slots" struct member in Python, thus the conflict was resolved.

Note: the Qt library is, like Python, old, and used in a huge number of projects and products. E.g. Qt is the base platform for KDE development. It's a matter of point of view, which of the two, Qt or Python should be "fixed".

In my PR I used the same solution: renaming the conflicting member.
-------------

Since this time this solution was not welcome, and obviously I'm not the first facing this issue, I was searching for another solutions.

I found that Qt has already provided a solution for this problem.

There are 2 macros: QT_NO_SIGNALS_SLOTS_KEYWORDS and QT_NO_KEYWORDS , which "turn off" defining the extension keywords as macros.
Instead the QT_SLOTS, Q_SIGNALS macros should be used, which very likely do not interfere with any 3rd party library...

Though, these are "official" Qt macros, not very well documented: https://bugreports.qt.io/browse/QTBUG-70564  :)

So by defining QT_NO_KEYWORDS I could resolve this whole issue.

Thanks guys for your patience and attetion!
:)