classification
Title: Regression: name of PyType_Spec::slots conflicts with Qt macro
Type: compile error Stage: resolved
Components: Versions: Python 3.9
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Leslie, benjamin.peterson, petr.viktorin, serhiy.storchaka, steve.dower, terry.reedy, vstinner
Priority: normal Keywords: patch

Created on 2019-09-02 10:23 by Leslie, last changed 2019-10-22 08:35 by petr.viktorin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 15644 closed Leslie, 2019-09-02 13:45
Messages (7)
msg350977 - (view) Author: (Leslie) * Date: 2019-09-02 10:23
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
msg351275 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-09-07 00:11
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.
msg351320 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-08 09:14
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.
msg351361 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-09-09 08:47
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.
msg351478 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-09-09 14:23
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.
msg351502 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2019-09-09 15:39
(You might also argue that Qt should be the ones fixing their namespacing.)
msg351796 - (view) Author: (Leslie) * Date: 2019-09-11 10:18
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!
:)
History
Date User Action Args
2019-10-22 08:35:09petr.viktorinsetnosy: + petr.viktorin
2019-09-11 10:18:49Lesliesetmessages: + msg351796
2019-09-09 15:39:34benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg351502
2019-09-09 14:23:46steve.dowersetstatus: open -> closed

nosy: + steve.dower
messages: + msg351478

resolution: rejected
stage: patch review -> resolved
2019-09-09 08:47:46vstinnersetmessages: + msg351361
2019-09-08 09:14:22serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg351320
2019-09-07 00:11:29terry.reedysetnosy: + vstinner, terry.reedy

messages: + msg351275
versions: - Python 3.6, Python 3.7, Python 3.8
2019-09-02 13:45:09Lesliesetkeywords: + patch
stage: patch review
pull_requests: + pull_request15309
2019-09-02 10:23:47Lesliecreate