Author scoder
Recipients eli.bendersky, flox, jcea, pitrou, python-dev, scoder
Date 2013-08-09.14:59:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1376060386.37.0.514540235802.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
> Well, I would rather like to understand yours.

My point is that the IncrementalParser uses a TreeBuilder that builds an XML tree in the back. So I'm wondering why you are saying that it doesn't build a tree.


> Whatever IncrementalParser uses internally needn't impact what API it
> exposes to the user.

And in fact, we don't even need an IncrementalParser, because XMLParser already *has* an incremental parsing interface. All that's missing is the bit that collects and exposes the events. And my point is that we shouldn't duplicate the existing *data entry* interface for that, especially not under different names for identical functionality, but only add an interface to access those events as *output*, i.e. to add the bit of the API that's actually missing.

As an analogon, what would you say if I asked for adding a new, separate Mapping interface to Python that uses the method name "set_value()" instead of "__setitem__()" because I want it to read data from the hard drive and not from memory?
History
Date User Action Args
2013-08-09 14:59:46scodersetrecipients: + scoder, jcea, pitrou, eli.bendersky, flox, python-dev
2013-08-09 14:59:46scodersetmessageid: <1376060386.37.0.514540235802.issue17741@psf.upfronthosting.co.za>
2013-08-09 14:59:46scoderlinkissue17741 messages
2013-08-09 14:59:46scodercreate