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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
