Serhiy: "As you said, calling close() can have side effects (for example invoking self._cont_handler.endDocument()). This was the argument against PR 1444. It seems to me that if _entity_stack is not empty (this happens in case of error in entity parsing) the close() method does nothing. And maybe there are other leaks in entity parsing."

Right, it seems that the conclusion is that there is not only a high risk of regression because of unexpected side effects, but also an issue with unknown external parsers.

So finally I moved backward and proposed my change on ExpatParser.parse():

* the change has a narrow scope: only ExpatParser.parse() is modified, external unknown code is not impact, low risk of regression for external parsers.

* the change is well defined: it does exactly one thing, it makes sure that the source is closed, especially the inner file object or urllib object. My change makes sure that the sure is always closed, even if the close() method does nothing.

According to the long list of constraints for this fix, I don't think that we can do better.

I made one design choice: the close() method of byte and character streams are called twice, I didn't call setByteStream(None) / setCharacterStream(None) to avoid creating an inconsistent source. If you really care, maybe we can reset the source to a new xmlreader.InputSource() object instead.