traceback.py and how it handles 'SyntaxError's, which includes a bunch of assumptions about attributes that a SyntaxError should have defined:
https://github.com/python/cpython/blob/master/Lib/traceback.py#L516
Definition of xml.etree.ElementTree.ParseError, marking it out as a sub-class of a SyntaxError:
https://github.com/python/cpython/blob/master/Lib/xml/etree/ElementTree.py#L106
How a ParseError is raised by ElementTree, noting that it doesn't set `filename` (and probably `text` too) as an attribute of the exception isntance:
https://github.com/python/cpython/blob/master/Lib/xml/etree/ElementTree.py#L1625
The most recent commit in the code areas I've highlighted is from `6bc2c1e7ebf359224e5e547f58ffc2c42cb36a39` from March 2015, which added in the assumptions about attributes to `traceback.py`.
The whole thing is markedly confusing, because the code in `traceback.py` isn't being run inside an exception handler, so when it crashes it completly obfuscates the actual root-cause of the issue (in other cases you'd get the "while handling this error, another happened" which is much more user friendly).
I'm not sure what the correct fix here is but I tried making xml.etree.ElementTree.ParseError a standalone exception, not a sub-class of SyntaxError but it didn't take. Probably shouldn't be delving about in the guts of the python-core on my laptop, but ho-hum.
|
➜
