Stefan Behnel added the comment: > XMLParser knows nothing about Elements, at least in the direct API of today. > The one constructing Elements is the target.
Absolutely. And I'm 100% for keeping that distinction exactly as it is. > The "read_events" method proposed for the new class (currently > IncrementalParser.events) already returns Elements, having used a TreeBuilder > to build them. More precisely, it only returns Elements *iff* the TreeBuilder builds them. If it does not, then it returns something else. By moving the desired functionality into the parser, we don't even need to change anything about the interface between the parser and the target object. We still can, though, if you want to extend the interface with start-ns and end-ns events (and I'm ok with that, but it's a different feature). We do not loose that option. But the cool thing is that we don't have to do this now, and that iterparse just keeps working as it is and can be fixed later. No deprecation needed. So we can easily agree on the goals of keeping the interface of the XMLParser simple and not teaching it about Elements. But we still disagree about the conclusions. My conclusion is that the API is substantially simpler if we do *not* add an entire new class that just duplicates existing APIs, but keep the parser as the thing that generates parse events. Be they in the form of callbacks or in the form of event tuples (that have the same name as the callbacks, BTW). The cool feature is that you can use either of the two interfaces or even hook into one to control the other (once the C parser is fixed), without having to learn the distinction between an XMLParser and a WhateverNewParser that also just parses XML. > I still want to be crystal clear it's a *parser* we're talking about You have to decide what you want. IMHO, there is no use in putting a new parser next to the existing XMLParser if both are there for parsing XML. That is just unnecessarily confusing. If you want it to be a parser, use the XMLParser. I guess there's no other way to convince you than by coding up my proposal. It seems to be hard to properly explain it without seeing it at work. ---------- _______________________________________ 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
