Thanks for the reviews, Kumar and Oleg!

For the path forward, there are two options: either pass state as a parameter, or store it in the type structs. I've created draft PRs for the two alternatives. Of course, a third path is a combination of both.

For the path forward, there are three options: either pass state as a parameter, store it in the type structs.

Both variants ultimately call PyModule_GetState, right? [with (1) caching its result into a field of self and (2) plainly calling it each time on demand]

If so, we need an informed decision by benchmarking some _elementtree method in both options. It should show whether direct structure access of (1) is faster than preheated call to PyModule_GetState of (2).

Both variants ultimately call PyModule_GetState, right?

PyModule_GetState is called for module level functions, PyType_GetModuleState for class methods (via defining class), and PyType_GetModuleByDef plus PyModule_GetState for slots. The two former are inexpensive lookups, the latter is slightly slower. Caching state in self results in more memory usage (might only be important for the Element type). I'd be surprised if it is possible to measure the performance impact of this, but sure let's do some benchmarking.

I ran the pyperformance xml_etree benchmark towards all three alternatives (1: pass state around as a parameter, 2: store state in the heap type contexts, 3: store state in TreeBuilder and XMLParser contexts, but pass it around for Element and its iter). I could not measure a significant difference any of the alternatives.

It won't matter as expected as most of the time as long as there isn't much stack spilling the performance should be identical.