Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Friesner (jfriesne) >Assigned to: Martin v. Löwis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 11:29 Message: Logged In: YES user_id=1188172 Assigning you again, Martin: should I change the names for 2.5? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2005-10-02 09:46 Message: 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. ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-30 17:38 Message: 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. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-30 10:44 Message: 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? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-29 22:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 22:48 Message: 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. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-29 22:37 Message: 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? ---------------------------------------------------------------------- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 18:59 Message: 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 ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-28 15:02 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
