Nick Coghlan added the comment: Stefan, your proposed merged design isn't going to happen. Two alternative ways of using the one class is far more complicated to explain to users than exposing a helper that composes the existing API components to address a particular use case (particularly when the helper is hiding the fact that the theoretical underlying composition doesn't currently work the way it should according to the public APIs).
As a higher level helper, users that are comfortable with and prefer the lower level API are then clearly free to ignore. This recasting of the nature of the API as a composition of the lower level components is a *direct* response to your concern about it being a capability that the lower level API should support directly. You clearly don't like that design choice, but this isn't a democracy. Arguing further on this point will just be ranting for the sake of ranting, rather than having any chance of changing Eli's mind as module maintainer. As far as naming goes, I still think it's better to drop "Parser" from the name entirely. Call it "XMLEventReader" or something like that. The point is to use it when you want to get the events out without blocking when no events have been triggered and don't want to set up your own class to receive event notifications through the target push API. The docs should make it clear that this API is "pull only" - if people need callbacks or other push triggers, then that's still what custom targets are for. ---------- _______________________________________ 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
