This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients eli.bendersky, scoder, serhiy.storchaka, vstinner
Date 2017-05-04.22:08:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493935699.2.0.478529273284.issue30264@psf.upfronthosting.co.za>
In-reply-to
Content
> What if the third-party parser don't use prepare_input_source()? It can use more efficient way if pass just a file name.

About "third-party parsers": I have no idea of what are these parsers. It seems like Jython uses provides a parser. But I'm not interested to test Jython, sorry!

> Wouldn't be better to move your code into the parser's method parse()? If a file is opened inside the parse() method and is not exposed outside, that method should close it.

I wrote a first patch putting the try/except into expatparser code, but then I found a second parser with a parse() method: IncrementalParser. In fact, the expat parser inherits from IncrementalParser. So I only modified IncrementalParser, and IncrementalParser calls the abstract method close(). So any parser implemented on top of IncrementalParser should get the fix for free.

My 3rd attempt (patch IncrementalParser.parse()) changes less code and IMHO is less error-prone.

Now, *in practice*, only the expat parser is used in CPython, and according to unit tests, my fix closes the file, so the bug is fixed!
History
Date User Action Args
2017-05-04 22:08:19vstinnersetrecipients: + vstinner, scoder, eli.bendersky, serhiy.storchaka
2017-05-04 22:08:19vstinnersetmessageid: <1493935699.2.0.478529273284.issue30264@psf.upfronthosting.co.za>
2017-05-04 22:08:19vstinnerlinkissue30264 messages
2017-05-04 22:08:19vstinnercreate