xml2rfc failing against lxml 3.3.1

hi IETF tools and LXML folks -- 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. What should be done here? (i've only just now tried to subscribe to the lxml mailing list and their subscription confirmation hasn't come through;, so i'm not sure this message will make it to their list. But i'm happy to try to follow up more with the lxml elsewhere if there are suggestions for a better way to get in touch, and if we determine that this isn't something we can fix cleanly in xml2rfc) Regards, --dkg

Hi, thanks for bringing this up. Daniel Kahn Gillmor, 25.02.2014 18:15:
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

Hi, thanks for bringing this up. Daniel Kahn Gillmor, 25.02.2014 18:15:
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
participants (2)
-
Daniel Kahn Gillmor
-
Stefan Behnel