Hi, thanks for bringing this up. Daniel Kahn Gillmor, 25.02.2014 18:15:
The IETF's xml2rfc tool (tested with versions 2.4.5 and 2.4.3) is failing for me when used with python's lxml module version 3.3.1. for example:
====================================================================== ERROR: test_header_footer (__main__.WriterDraftTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "./test.py", line 264, in setUp self.parse('tests/input/draft_root.xml') File "./test.py", line 222, in parse self.xmlrfc = self.parser.parse() File "/home/dkg/src/xml2rfc/xml2rfc/xml2rfc/parser.py", line 408, in parse context.resolvers.add(caching_resolver) AttributeError: 'lxml.etree.iterparse' object has no attribute 'resolvers'
This was not a problem when i used lxml 3.2.0.
I haven't dived deep into lxml yet, but looking in the upstream changelog at https://github.com/lxml/lxml/blob/master/CHANGES.txt, i see:
* The externally useless class ``lxml.etree._BaseParser`` was removed from the module dict.
and lxml.etree._BaseParser does have a "resolvers" attribute.
So if i'm interpreting this right, either lxml upstream was mistaken about the idea that _BaseParser is externally useless (because it's being used by xml2rfc), or xml2rfc needs to find another way to set up its caching resolvers.
The relevant changelog entry is actually this: * ``iterparse()`` was rewritten to use the new ``*PullParser`` classes internally instead of being a parser itself. Meaning: it no longer inherits from _BaseParser (which really was externally useless, because it couldn't be instantiated anyway). Essentially, iterparse() being a parser was a design bug from the very beginning.
What should be done here?
The fact that the "resolvers" property got lost was mainly due to an incomplete refactoring during a long, political fight regarding the future ET/lxml compatibility of the parsers. While I'm planning to deprecate and clean up the current overly packed interface of iterparse() at some point, breaking backwards compatibility wasn't intended for 3.x. Due to the unclear situation in ElementTree, the newly designed pull parser API still isn't in a state that can completely replace the old API, so what I did now is to restore the missing properties and methods on iterparse(), so that they'll be available in lxml 3.3.2 again (which I was already planning to release soonish). https://github.com/lxml/lxml/commit/976c463249d41953c91ec3d07db7ecd9c56fc3fa Sorry for the inconvenience. Stefan