Hello,Here is a patch documentingPEP 489.I don't feel comfortable rewriting the tutorial [0] yet: before the issue with callbacks/module state [1] is solved, which is 3.6 material, multi-phase init is not suitable for all modules.So everything inPEP 489 is described in reference-style documentation.[0]https://docs.python.org/3/extending/extending.html[1]https://www.python.org/dev/peps/pep-0489/#module-state-and-c-level-callbacks

Leaving the tutorial alone until the callback problem is resolved makes sense to me.The patch overall looks good, I sent a few more detailed comments via Rietveld.

Thanks for the review.I've added the explanation you suggested, and I've made the names monospace (or linked them, where it seemed appropriate). I've also marked *NULL*s like in the rest of the doc.

New changesetbad92d696866 by Nick Coghlan in branch '3.5':Close#24458:PEP 489 documentationhttps://hg.python.org/cpython/rev/bad92d696866New changeset86daa37c1cc9 by Nick Coghlan in branch 'default':Merge fix for#24458 from 3.5https://hg.python.org/cpython/rev/86daa37c1cc9

Thanks and, as you can see, merged :)Am I correct in thinking these docs were the only item remaining forPEP 489?

Yes!Aside from the callback problem, which is left for another PEP, but limitsPEP 489 usefulness in the real world :(It turns out that one is quite a rabbit hole. I'll post my findings on that soon-ish.

Sorry I didn't get a review in before.  Since subinterpreters and multi-phase initialization are on my mind, I have a couple questions:Should there be a note in the "Single-phase initialization" section (perhaps at the top of the section) that encourages use of multi-phase initialization?Would it be worth demonstrating how a module might be verified to work with subinterpreters (as indicated in the multi-phase section)?  An example with a brief main function would likely be sufficient.  If it's not obvious how to do it then module authors may not consider it worth the trouble.  If all goes well then subinterpreters will be exposed in Python in 3.6 which will make such testing much easier.

What is the level of impact of the callback problem?  Of the 4 scenarios in [1], it seems to me like #1 (C callbacks w/o a module reference) would be the most common.  However, can't that be addressed by adjusting the API, so it would only be a big problem in the case of a public C-API for the module (where backward-compatibility is a concern)?  #3 (classes have no reference to the module) sounds like the most problematic but how common a problem is it practice?It may be worth including an explicit note in the multi-phase section on the scenarios that currently don't lend themselves well to multi-phase initialization.  It would also be great to indicate how to work around those issues (or the cases where for now it's better to just use single-phase initialization).FWIW, the matter ties in directly to the work I'm doing with subinterpreters right now.[1]https://mail.python.org/pipermail/import-sig/2015-April/000959.html

Verifying modules to work ith subinterpreters is tricky. What level of assurance do you want?Subinterpreters themselves require that you embed Python, which doesn't lend itself to an easy example. I hope 2.6 makes the situation better.Example code is in xxmodule, which is mentioned.The #3 problem is pretty common, unfortunately: if you define a Database class and a Record class, Database objects can't get to the Record class to instantiate it. If you define a module-level exception, methods of other classes can't easily raise it.I think recommending workarounds/solutions needs some more discussion; I plan to summarize my thoughts on a mailing list soonish.