Author ncoghlan
Recipients eli.bendersky, ethan.furman, flox, jcea, jkloth, ncoghlan, python-dev, scoder
Date 2013-08-27.09:25:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7d2CyfpPdbcykWut4N0xBjbYdO4TY2b0doCwRH1YbpHdQ@mail.gmail.com>
In-reply-to <1377587752.16.0.513918110729.issue17741@psf.upfronthosting.co.za>
Content
The whole point of the new API is not to replace XMLParser, but to
provide a convenience API to set up a particular combination of an
XMLParser with a particular kind of custom target. It just happens
that actually *implementing it* that way doesn't work right with the
current code. It is *not* necessary (or even appropriate) for it to
serve as a new building block, but as a convenience API to compose
*existing* building blocks in a particular way (or should be, except
that composition doesn't currently work right).

Once the underlying deficiencies are fixed, then the event capturing
target can be exposed directly, but in the meantime, the *composed*
version can be exposed by relying on internal APIs.

We could call the new class XMLParserWithEventCapturingTarget, but
that's a little clumsy :)
History
Date User Action Args
2013-08-27 09:25:57ncoghlansetrecipients: + ncoghlan, jcea, scoder, jkloth, eli.bendersky, flox, ethan.furman, python-dev
2013-08-27 09:25:57ncoghlanlinkissue17741 messages
2013-08-27 09:25:57ncoghlancreate