A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-May/089398.html below:

[Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

[Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDefLarry Hastings larry at hastings.org
Mon May 4 22:29:19 CEST 2009
Mark Dickinson wrote:
> I *think* that third party code that's recompiled for 3.1 and that
> doesn't use the closure field will either just work, or will produce an
> easily-fixed compile error.  Larry, does this sound right?
>   

Yep.

> But I guess the bigger issue is that extensions already compiled against 3.0
> that use PyGetSetDef (even if they don't make use of the closure field)
> won't work with 3.1 without a recompile:  they'll segfault, or otherwise behave
> unpredictably.
>   

Well, I think they'd work if they didn't use the closure and they had 
only one entry in their array of PyGetSetDefs.  But more than one, and 
yes it would behave unpredictably.  Probably segfault.

> If that's not considered a problem, then surely we ought to be getting rid of
> tp_reserved?

In principle they are equivalent, but in practice removing tp_reserved 
is a much bigger change.  Removing the closure field would result in 
obvious compile errors, and plenty of folks wouldn't even experience 
those.  Removing tp_reserved would affect everybody, with inscrutable 
compiler errors.

Personally I'd be up for removing tp_reserved.  But I lack the caution 
regarding backwards compatibility that has served Python so well, so 
you're ill-advised to listen to me.


Daniel Stutzbach wrote:
> I was under the impression that binary compatibility was only 
> guaranteed within a minor revision (e.g., 2.6.1 must run code compiled 
> for 2.6.0, but 2.7.0 doesn't have to).  I've been wrong before, though.

My understanding is that that's the explicit guarantee.  However Python 
has been well-served by being much more cautious than that, a policy 
with which I cannot find fault.

> Certainly the C extension module I maintain is sprinkled with #ifdef's 
> so it will compile under 2.5, 2.6, and 3.0. ;-)

Happily this is one change where you could maintain backwards 
compatibility without #ifdefs.  If you use the closure field, change 
your code to use stub functions and pass the closure data in yourself.


/larry/
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4