Author scoder
Recipients eli.bendersky, flox, jcea, jkloth, ncoghlan, python-dev, scoder
Date 2013-08-26.08:31:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377505905.69.0.867018738914.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
I don't see adding one method to XMLParser as a design problem. In fact, it's even a good design on the technical side, because if ET ever gains an HTMLParser, then the implementation of this feature would be highly dependent on the underlying parser, i.e. it would be very different from the implementation in XMLParser. It might not even be supported at all. Moving the API into the parser gives us that choice quite naturally.

It also solves the naming issue. Why add another thing to the module that needs explanation (and even an explanation why it's there and how it's different from what else is there), when we can just add the feature to what's there and be done?
History
Date User Action Args
2013-08-26 08:31:45scodersetrecipients: + scoder, jcea, ncoghlan, jkloth, eli.bendersky, flox, python-dev
2013-08-26 08:31:45scodersetmessageid: <1377505905.69.0.867018738914.issue17741@psf.upfronthosting.co.za>
2013-08-26 08:31:45scoderlinkissue17741 messages
2013-08-26 08:31:45scodercreate