[Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

[Dino Viehland]

>
> That's exactly why I dislike "New", it's like adding "Ex" or "2" to a
> function name :-)
>
> Well, before bikeshedding on the C define name, I would prefer to see
> if the overall idea of trying to push code for the new C API in the
> master branch is a good idea, or if it's too early and the experiment
> must continue in a fork.


Rather than adding yet another pre-processor directive for this I would
suggest just adding a new header file that only has the new stable API.
For example it could just be "py.h" or "pyapi.h".  It would have all of the
definitions for the stable API.

While that would involve some duplication from the existing headers, I
don't think it would be such a big deal - the idea is the API won't change,
methods won't be removed, and occasionally new methods will get
added in a very thoughtful manner.  Having it be separate will force
thought and conversation about it.

It would also make it very easy to look and see what exactly is in the
stable API as well.  There's be a pretty flat list which can be consulted,
and hopefully it ends up not being super huge either.

BTW, thanks for continuing to push on this Victor, it seems like great
progress!

On Fri, Nov 9, 2018 at 4:57 PM Victor Stinner <vstinner at redhat.com> wrote:

> Le sam. 10 nov. 2018 à 01:49, Michael Selik <mike at selik.org> a écrit :
> >> It uses an opt-in option (Py_NEWCAPI define -- I'm not sure about the
> >> name) to get the new API. The current C API is unchanged.
> >
> > While one can hope that this will be the only time the C API will be
> revised, it may be better to number it instead of calling it "NEW". 20
> years from now, it won't feel new anymore.
>
> That's exactly why I dislike "New", it's like adding "Ex" or "2" to a
> function name :-)
>
> Well, before bikeshedding on the C define name, I would prefer to see
> if the overall idea of trying to push code for the new C API in the
> master branch is a good idea, or if it's too early and the experiment
> must continue in a fork.
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dinoviehland%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181109/a442e92b/attachment.html>