Stefan Behnel added the comment: Hmm, did you look at my last comment at all? It solves both the technical issues and the API issues very nicely and avoids any problems of potential future changes. Let me quickly explain why.
The feature in question depends on two existing parts of the API: the event generation of the parser, and the return values of the parser target (e.g. a tree builder). So there are really only three places where this feature makes sense, both technically and API-wise. 1) in the target 2) in the parser 3) between parser and target Note how a separate class is ruled out right from the start by the fact that the feature lives somehwere between parser and target. It's an inherent part of the existing design already (and of the implementation, BTW), so I don't see how adding a separate thing to control it makes any sense. 1) is impossible because the target is user provided and we do not control it 2) works fine because the parser controls both the call to the target and its return value 3) would be nice (and was my original favourite) but is hard to do with the current implementation and requires further changes to the API of parser targets So 2) is the choice that remains. > It will *not* accept a "parser" argument in the constructor. Yes, I had also arrived at that point yesterday. However, I then reconsidered why there has to be a separate class in the first place. Basically, if you can't allow users to control the parser because the feature is already part of the parser, then why expose it as something that appears to be independent? Adding it to the existing API is very clean and exposes the feature where users would look for it. > EventParser's output-side method will be called "read_events". Makes sense to me. I had also considered that problem but didn't come up with a good name yet. "read_events" reads better than plain "events". > The class will be named EventParser. Obviously because it's parsing Events, as opposed to the XMLParser, which parses XML, or the HTMLParser, which parses HTML, right? ---------- _______________________________________ 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
