> > 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 <vstin...@redhat.com> wrote: > Le sam. 10 nov. 2018 à 01:49, Michael Selik <m...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dinoviehland%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
