Hi @matrixise, Do you wish to finish up this PR or would you like me to do so? Thanks!

@willingc I will finish this PR, really sorry, I will work on it on this evening.

Hi all, @ncoghlan @willingc and @Mariatta I have fixed this PR with the recommendations of @ncoghlan

Please, when you have time, review.

I am so sorry for this late reply.

Do we really need to create a separate document just for four links? I think the most up-to-date and detailed resource is https://pythonextensionpatterns.readthedocs.io/en/latest/ and it was already linked in the Devguide in #279.

We really should have more than just the 4 links - referencing the C style guide, pointers to test_embed and test_capi, etc, start building out some extra docs for internal helper functions, etc.

It would make sense to mention that as a ReST comment though, otherwise it isn't clear why we're adding such a bare bones page in the first place.

It would make sense to mention that as a ReST comment though, otherwise it isn't clear why we're adding such a bare bones page in the first place.

I don't think "we'll finish this later" is a good argument for merging this PR. A TODO comment can easily be forgotten in a short time. And after two years or so, someone is going to submit a PR to remove extensions.rst because it doesn't contain any useful information.

Please don't make the Devguide a place for unfinished and half baked documents.

@berkerpeksag ok, but where will you put these links?

PEP 399 can be mentioned at https://devguide.python.org/runtests/#writing (test.support is already mentioned) https://pythonextensionpatterns.readthedocs.io/en/latest/ is the hardest resource to find on Google and it's already mentioned in the Devguide. The rest can be found with a simple Google search such as "python c extension".

"You can find this information via Google if you already know what to look for, and how to interpret the results" isn't a particularly helpful attitude for us to adopt when writing documentation aimed primarily at new CPython contributors.

If starting the section out with just a few links really bothers you, then rather than saying "This doesn't have enough content, so reject it", I'd prefer to see this new section extended a bit to also cover:

• how to add a new extension module via Modules/Setup.dist
• how to add a new extension via the Makefile and the MSVS build process
• how to convert an extension module into a builtin module instead

"You can find this information via Google if you already know what to look for, and how to interpret the results" isn't a particularly helpful attitude for us to adopt when writing documentation aimed primarily at new CPython contributors.

Most of these links are from our own documentation and don't have anything to do with contributing to CPython (except PEP 399) People can read them to learn how to write Python extensions for their own projects. We don't explain how to use unittest or how to write unit tests in the devguide. We only give information specific to CPython (how to use regrtest, how to find memory leaks by using regrtest, how to make coveragepy work with extension modules, test.support etc.)

If starting the section out with just a few links really bothers you, then rather than saying "This doesn't have enough content, so reject it", I'd prefer to see this new section extended a bit to also cover:

Your suggestions sound good to me. I'd like to see a action about how to test a C API function (by using Modules/__testcapimodule.c and Lib/test_capi.py) I'm volunteering to write it or I can help Stéphane if he'd like to do it himself.