This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients eli.bendersky, flox, jcea, jkloth, ncoghlan, python-dev, scoder
Date 2013-08-26.05:40:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377495644.65.0.193687256987.issue17741@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2013-08-26 05:40:44scodersetrecipients: + scoder, jcea, ncoghlan, jkloth, eli.bendersky, flox, python-dev
2013-08-26 05:40:44scodersetmessageid: <1377495644.65.0.193687256987.issue17741@psf.upfronthosting.co.za>
2013-08-26 05:40:44scoderlinkissue17741 messages
2013-08-26 05:40:44scodercreate