[Patches] [ python-Patches-1718153 ] PEP 3123 implementation

Sat Jul 21 20:52:16 CEST 2007

Patches item #1718153, was opened at 2007-05-13 16:21
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718153&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: None
Group: Python 3000
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: PEP 3123 implementation

Initial Comment:
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

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2007-07-21 20:52

Message:
Logged In: YES 
user_id=21627
Originator: YES

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.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-21 17:05

Message:
Logged In: YES 
user_id=6380
Originator: NO

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!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-07-21 11:06

Message:
Logged In: YES 
user_id=21627
Originator: YES

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.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 10:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-07-12 10:16

Message:
Logged In: YES 
user_id=21627
Originator: YES

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.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-12 09:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-07-11 23:43

Message:
Logged In: YES 
user_id=21627
Originator: YES

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?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-07-11 14:38

Message:
Logged In: YES 
user_id=6380
Originator: NO

Is this ready to be committed?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-05-23 23:55

Message:
Logged In: YES 
user_id=21627
Originator: YES

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

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-23 07:29

Message:
Logged In: YES 
user_id=33168
Originator: NO

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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1718153&group_id=5470