Issue1086854
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2004-12-17 04:07 by jfriesne, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (12) | |||
---|---|---|---|
msg23751 - (view) | Author: Jeremy Friesner (jfriesne) | Date: 2004-12-17 04:07 | |
This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. |
|||
msg23752 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2005-09-28 13:02 | |
Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? |
|||
msg23753 - (view) | Author: Jeremy Friesner (jfriesne) | Date: 2005-09-28 16:59 | |
Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip |
|||
msg23754 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2005-09-29 20:37 | |
Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? |
|||
msg23755 - (view) | Author: Jeremy Friesner (jfriesne) | Date: 2005-09-29 20:48 | |
Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. |
|||
msg23756 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2005-09-29 20:50 | |
Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. |
|||
msg23757 - (view) | Author: Michael Hudson (mwh) | Date: 2005-09-30 08:44 | |
Logged In: YES user_id=6656 I'm not particularly convinced that this is a great idea. Python uses 'new' and 'class' as C identifiers which mean you can't compile it as C++ -- but Python isn't written in C++, so this is fine. Similarly, Python isn't designed to be fed to moc -- so why feed it to moc? |
|||
msg23758 - (view) | Author: Jeremy Friesner (jfriesne) | Date: 2005-09-30 15:38 | |
Logged In: YES user_id=383828 On second thought, I believe mwh is right; most of those changes are unnecessary. (I made the changes a long time ago, so when I grepped for them the other day the memory for their motivation wasn't fresh). The Python .c files aren't fed to moc, so references to 'signals' and 'slots' in the .c files should compile okay. It's just the references to those identifiers in the Python .h files that cause a problem, if the .h files are #included in a Qt-using C++ program, after #including a Qt header. So I think probably just the original three changes are sufficient. |
|||
msg23759 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2005-10-02 07:46 | |
Logged In: YES user_id=21627 I would assume that the changes are necessary *only* in header files, which means that only heaptype is to be changed. I don't know what happened to the old principle of protecting struct members against name collisions; I think if they are to be renamed, their names should be ht_type, ht_name, ht_slots. (I never understood the rationale for this convention until this report: there always might be a collision with a macro name). Unfortunately, such a change is not so easy as it may sound: it may break existing applications. Still, I think it should be done, but only for 2.5. Unassigning myself. |
|||
msg23760 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2006-02-20 10:29 | |
Logged In: YES user_id=1188172 Assigning you again, Martin: should I change the names for 2.5? |
|||
msg23761 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2006-02-20 21:46 | |
Logged In: YES user_id=21627 Sure! |
|||
msg23762 - (view) | Author: Georg Brandl (georg.brandl) * | Date: 2006-02-20 22:27 | |
Logged In: YES user_id=849994 Done in rev. 42531. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:08 | admin | set | github: 41335 |
2004-12-17 04:07:56 | jfriesne | create |