On May 17, 2009, at 4:54 PM, Martin v. Löwis wrote:
Currently, each feature release introduces a new name for the
Python DLL on Windows, and may cause incompatibilities for extension
modules on Unix. This PEP proposes to define a stable set of API
functions which are guaranteed to be available for the lifetime
of Python 3, and which will also remain binary-compatible across
versions. Extension modules and applications embedding Python
can work with different feature releases as long as they restrict
themselves to this stable ABI.
It seems like a good ideal to strive for.
But I think this is too strong a promise. IMO it would be better to
say that ABI compatibility across releases is a goal. If someone does
make a change that breaks the ABI, I'd expect whomever is proposing it
to put forth a fairly strong argument towards why it's a worthwhile
change. But it should be possible and allowed, given the right
circumstances. Because I think it's pretty much inevitable that it
*will* need to happen, sometime.
(of course there will need to be ABI tests, so that any potential ABI
breakages are known about when they occur)
Python is much more defined by its source language than its C
extension API, so tying the python major version number to the C ABI
might not be the best idea from a "marketing" standpoint. (I can see
it now..."Python 4.0 major new features: we changed the C method
definition struct layout incompatibly" :)
James
_______________________________________________
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
