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 callPyModule_GetState, right? [with(1) caching its result into a field ofself 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 toPyModule_GetState of(2).

Both variants ultimately callPyModule_GetState, right?

PyModule_GetState is called for module level functions,PyType_GetModuleState for class methods (via defining class), andPyType_GetModuleByDef plusPyModule_GetState for slots. The two former are inexpensive lookups, the latter is slightly slower. Caching state inself 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 pyperformancexml_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.