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

[SourceForge.net]

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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
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-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