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. 
 

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?

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

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?

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. 

Logged In: YES 
user_id=1188172

Ah, okay. However, I can't decide whether this will be done,
assigning to Martin for this case.

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?

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.

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.

Logged In: YES 
user_id=1188172

Assigning you again, Martin: should I change the names for 2.5?

Logged In: YES 
user_id=21627

Sure!

Logged In: YES 
user_id=849994

Done in rev. 42531.