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-05.09:45:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493977501.29.0.459015753903.issue30264@psf.upfronthosting.co.za>
In-reply-to
Content
> This changes the behavior if pass a file object to the parser. When the parser failed it was possible to use the passed file object (for example call tell()). Now it is closed.

If the high-level *function* parse() is called with a filename, the caller doesn't have access to the file object nor the parser.

If you use directly the parser class and pass an open file object, in that case, yes, my change closes the file.

If you want to keep the old behaviour for that case, we can change the code to only close the source if source is not a string (not isinstance(source, str)) in the ExpatParser.parse() method. Since the caller owns the file object, (s)he is responsible to close it.

Note: on parser success, the source is always closed, even if the user pass an already open file object.

I'm not convince that using the file object on parser error and using directly the ExpatParser class is a common use case. I expect that the XML parser reads more data than it needs (read ahead for speed), so I don't think that file.tell() will you exactly the file position where the XML parser failed.
History
Date User Action Args
2017-05-05 09:45:01vstinnersetrecipients: + vstinner, scoder, eli.bendersky, serhiy.storchaka
2017-05-05 09:45:01vstinnersetmessageid: <1493977501.29.0.459015753903.issue30264@psf.upfronthosting.co.za>
2017-05-05 09:45:01vstinnerlinkissue30264 messages
2017-05-05 09:45:01vstinnercreate