Stefan Behnel added the comment:

"""
TreeBuilder has to support an explicit API for collecting and reporting events. 
XMLParser has to call into this API and either not have _setevents at all or 
have something public and documented. Note also that event hookup in the parser 
makes sense in a way, because we don't want events to be fired when not needed 
(for performance). So we don't want any parser to hook up all events for 
firing, and only incremental tree builders to collect them.
"""

That's why I wanted to introduce the wrapper class. The idea was to extend the 
supported methods on the target object by those needed for iterparse(), 
specifically start_ns() and end_ns(). That way, the event callback setup would 
be just natural.


"""
In addition, since iterparse (an existing, stable API of the module) expects a 
parser argument, it won't be easy creating an IncrementalTreeBuilder, because 
how would we let people using custom parsers with iterparse not change any code 
and yet keep things working?
"""

Yep, that's a problem in the original design.

One way to fix it would be to allow changing the parser target after the 
creation of the parser, but before it actually started parsing. That could be 
an entirely internal feature that would then allow injecting the wrapper 
between the parser and the target after the fact. 

Given that the current support for using different parsers in iterparse() is 
pretty much non-existant, requiring the applicable parsers to support this 
feature would not be a regression, IMHO.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to