Author eli.bendersky
Recipients eli.bendersky, flox, jcea, ncoghlan, python-dev, scoder
Date 2013-08-24.23:07:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377385651.89.0.0793672497782.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
I like the idea of having .events() in a special target passed to a XMLParser, which already has feed() and close(). I read through Stefan's proposal and there are a couple of issues I wanted to raise:

1. Why have the "event builder" wrap a tree builder? Can't it just be a separate target?
2. Instead of the stock XMLParser recognizing the event builder via isinstance and giving it special treatment, would it not be better to still have a separate class that implements the XMLParser interface (it can derive from it or just use duck typing)?

Note that (2) brings us closer to Antoine's original design, albeit with different method names and somewhat different underlying implementation.

Also, Stefan, could you clearly explain the specific implementation issue you ran into with your partial patch. You mentioned an unrelated bug that can/should be solved before such an implementation can work. Can you provide more details?
History
Date User Action Args
2013-08-24 23:07:31eli.benderskysetrecipients: + eli.bendersky, jcea, ncoghlan, scoder, flox, python-dev
2013-08-24 23:07:31eli.benderskysetmessageid: <1377385651.89.0.0793672497782.issue17741@psf.upfronthosting.co.za>
2013-08-24 23:07:31eli.benderskylinkissue17741 messages
2013-08-24 23:07:31eli.benderskycreate