On Mon, 13 Apr 2020 at 11:20, Steve Dower email@example.com wrote:
On 11Apr2020 1156, Rhodri James wrote:
On 10/04/2020 18:20, Victor Stinner wrote:
Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython.
If this is true, the documentation on python.org needs a serious rewrite. I am in the throes of writing a C extension, and using Cython or cffi never even crossed my mind.
Sorry you missed the first two sections: "Recommended third party tools" and "Creating extensions without third party tools".
If you have any suggestions on how to make this recommendation more obvious, please open an issue and describe what would have helped.
Personally, I'd say that "recommended 3rd party tools" reads as saying "if you want a 3rd party tool to build extensions, these are good (and are a lot easier than using the raw C API)". That's a lot different than saying "we recommend that people writing C extensions do not use the raw C API, but use one of these tools instead".
Also, if we *are* going to push people away from the raw C API, then I think we should be recommending a particular tool (likely Cython) as what people writing their first extension (or wanting to switch from the raw C API for the first time) should use. Faced with the API docs, and a list of 3rd party options, I know that *I* am likely to say "yeah, leave that research for another day, I'll use what's in the docs in front of me for now". Also, if we are expecting to push people towards 3rd party tools, that seems to me to be a relatively significant shift in emphasis, and one we should be publicising more directly (via What's New, and blog postings / release announcements, etc.) In the absence of anything like that, I think it's quite reasonable for people to gravitate towards the traditional C API.
Having said all this, I *do* think that promoting some 3rd party tool (as I say, I suspect this would be Cython) as the recommended means of writing C extensions, is a reasonable approach to take. I just object to it happening "quietly" via changes like this which make it harder to use the raw C API, justifying themselves by saying "you shouldn't do that anyway".
On a related but different note, what is the recommended policy (assuming it's not to use the C API) for embedding Python, and for exposing the embedding app to Python as a C extension? My standard example of this is the Vim interface to Python - see https://github.com/vim/vim/blob/master/src/if_python3.c. I originally wrote this back in the Python 1.5 days, so it's *very* old, and quite likely not how I'd write it now, even using the C API. But what's the recommendation for code like that in the face of these changes, and the suggestion that using 3rd party tools is the normal way to write C extensions?