[Python-3000] how should we handle changes to the C API?

[Brett Cannon]

On 2/10/07, Guido van Rossum <guido at python.org> wrote:
> On 1/29/07, Brett Cannon <brett at python.org> wrote:
> > I was more generally wondering what the plan was for transitioning any
> > C API changes (if we were even going to do that level of transition).
>
> It's too early for much of a plan IMO. I'm not making radical changes
> (yet) but I'm mercilessly deleting APIs as they become obsolete. I
> expect that we need to wait until we've implemented the new I/O
> library and the str/unicode unification before we can say much about
> what to do about C APIs.
>

OK, fair enough.  I know Neal has some ideas on this so I can let him
sweat some of the details when it comes time.  =)

> But there's one thing we can do: not change existing APIs in
> incompatible ways. If you delete an API, code that uses it gets a
> compile-time error, and that should make it relatively simple to fix
> (assuming there's a replacement). But if you change the signature it's
> more questionable, and if you change the semantics (e.g. returning a
> different kind of PyObject*) it's painful.
>
> So let's commit to not changing signatures or semantics, but delete
> obsolete APIs in favor of new ones (with a different name). I guess
> this means some of the new names will be ugly. So what, it's C. :-)

Thank goodness for documentation and the C API index then.  =)

Then I will probably try to come up with a reasonable name for
something to replace PyErr_GivenExceptionMatches(), add it to 2.6, and
delete PyErr_GivenExceptionMatches() in 3.0.

-Brett