Changes by Eli Bendersky eli...@gmail.com:
--
resolution: - wont fix
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14852
___
Eli Bendersky eli...@gmail.com added the comment:
I propose to close this issue. If the problem in json is real and someone
thinks it has to be fixed, a separate issue specifically for json should be
opened.
--
___
Python tracker
Eli Bendersky eli...@gmail.com added the comment:
I don't think this is an enhancement to ET, because ET was not designed to be a
streaming parser, which is what is required here. ET was designed to read a
whole valid XML document. There is 'iterparse', as Antoine mentioned, but it is
Éric Araujo mer...@netwok.org added the comment:
I am not sure the parsers should be lenient. One could argue that it’s the
stream that is broken if it contains non-compliant XML or JSON. Can you tell
more about the use case?
--
nosy: +eli.bendersky, eric.araujo, ezio.melotti,
Antoine Pitrou pit...@free.fr added the comment:
ElementTree supports incremental parsing with the iterparse() method, not sure
it fills your use case:
http://docs.python.org/dev/library/xml.etree.elementtree.html#xml.etree.ElementTree.iterparse
As for the json module, it doesn't have such a
Frederick Ross madhad...@gmail.com added the comment:
Antoine, It's not iterative parsing, it's a sequence of XML docs or json
objects.
Eric, the server I'm retrieving from, for real time searches, steadily produces
a stream of (each properly formed) XML or json documents containing new
R. David Murray rdmur...@bitdance.com added the comment:
I think it is perfectly reasonable for a parser to leave the file pointer in
some undefined further location into the file when it detects extra stuff and
produces an error message. One can certainly argue that producing that error
Frederick Ross madhad...@gmail.com added the comment:
In the case of files, sure, it's fine. The error gives me the offset, and I can
go pull it out and buffer it, and it's fine. Plus XML is strict about having
only one document per file.
For streams, none of this is applicable. I can't seek
R. David Murray rdmur...@bitdance.com added the comment:
Well, if the stream isn't seekable then I don't see how it can be left in any
state other than the same one it leaves a file (read ahead as much as it read
to generate the error). So unfortunately by our backward compatibility rules I
New submission from Frederick Ross madhad...@gmail.com:
When parsing something like 'ax/aay/a' with xml.etree.ElementTree, or
'{}{}' with json, these parser throw exceptions instead of reading a single
element of the kind they understand off the stream (or throwing an exception if
there is no
10 matches
Mail list logo
