This patch implements the changes need for PEP 3123, in Py3k. Rather than checking this into the 3k branch, a backport of those bulk of the patch to 2.6 should be made, omitting the actual changes to PyObject_HEAD

I like this patch would like it to be applied to 2.6.  However, I'm concerned about extension modules maintaining compatibility for 2.5 and 3.0.  What would that look like (ie, an extension module that can compile with both versions)?  How would the modules need to be changed to support both versions?  For Py_{Type,Refcnt,Size}, it looks pretty straightforward to define the macros in 2.x and things should work fine.  But I'm not sure about the HEAD_INIT macros.

Martin, did you try disabling the -fno-strict-aliasing with this patch to see if there were any warnings?

I don't think API compatibility between 2.5 and 3.0 should be a requirement - I expect that there will be much more breakage, making such compatibility very difficult for other reasons.

Anyway, for everything that can be done with a macro (including HEAD_INIT), code that wants compatibility with 2.5 and earlier should do

#ifndef MACRO
#define MACRO 2.6-content of macro
#endif

Is this ready to be committed?

Depends on the precise procedure to follow. I have a patch that works for 2.6 (but it's not included here); should I commit that?

Hm. How fully backwards compatible is the patch? As part of the Py3k transition strategy, I've been trying to paint a picture of the transition from 2.x to 2.6 as super-easy, because we're not changing any existing functionality, we're just adding Py3k forward compatibility features that are easily ignoreable. Even if only 5% of 3rd party extension modules were to need work because of this change, that would already defeat the purpose IMO.

OTOH I'm all for doing this in 3.0.  If the 2.6 changes are fully compatible I have no objection in doing it there as well.

The 2.6 version of the patch is fully backwards-compatible. It provides a few new macros, and reformulates a lot of code to use these macros. The 3.0 version of the same macros looks different; for 2.6, these macros don't have to be used - but I propose to use them in the core anyhow to avoid the two code bases diverging.

OK, sounds like this is fully compatible with 2.5.  So we will have two compatibility ranges: [2.5, 2.6] and [2.6, 3.0] (but these use different code variants).

To submit it, I propose the following procedure:

1. merge trunk -> p3yk (this should be easy as we've done this regularly and recently)

2. merge p3yk -> py3k-struni (ditto)

3. submit this patch to the trunk

4. merge trunk -> p3yk (I fear this will require lots of conflict resolutions)

5. merge p3yk -> py3k-struni (I expect some but not many conflicts)

I hope you can do all these; you know most about the code so you're most likely to be able to pull off #4 successfully.

I found that steps 1 and 2 where not necessary, since you already had done 
merging before I started. I then did 3 and 4, with these commits:

r56476: 2.6 changes
r56477: merged to 3k
r56478: change struct inheritance
r56479, 56480: fix strict-aliasing bugs related to True/False; many more remain

Now I'm stuck; trying to do "merge -S p3yk" in the py3k-struni branch gives me
a conflict on ".", and dir_conflicts.prej says

Trying to change property 'svnmerge-integrated' from '/python/trunk:1-56465' to '/python/trunk:1-56476',
but property already exists with value '/python/branches/p3yk:1-56466 /python/trunk:1-54987'

I don't know how to fix this.

If the only conflict left is on '.', I've always gotten away with just saying "svn resolved ." -- I have no idea why it does that but it seems innocuous.  Generally you also need to do another svn up (which typically doesn't do anything) before the submit passes.

Thanks for getting this in!

Ok, I merged the 3k branch to struni in 56483, and then fixed the resulting breakage in 56484.

So I think this PEP is done.