Stefan Behnel added the comment:
> the push API is inactive and gets redirected to a pull API
Given that this is aimed to become a redundant 'convenience' wrapper around
something else at a point, I assume that you are aware that the above is just
an arbitrary restriction due to the fact that the parser does not accept
arbitrary targets as input.
Also, the refrence to pulldom is a bad one, because pulldom reads data as you
request it ("pull"). This class creates events based on the data you *push*
into it. So it's really a push API from the POV of the user, not so much a pull
API.
Anyway, it should be possible to emulate both this class and the pie-in-the-sky
three-level API based on what I suggested, so I can't see this addition being a
problem. I may even end up making the same visual split in lxml.etree
deliberately, in order to make it clear that this feature only applies to the
push parser API, i.e. when using feed() and close(), as opposed to what parse()
and fromstring() use. That would mean that there'd also be a corresponding
class for the HTMLParser then, and both would inherit from the base parsers and
thus obviously (and conveniently) accept arbitrary parser targets.
I think I'm ok with adding that class. I liked Greg Ewing's suggestion of
calling it AsyncParser, though, i.e. AsyncXMLParser. It makes it obvious what
the use case is and avoids any references to push or pull that will always
confuse some users, based on what part of the feature they are focussing on in
their code.
----------
_______________________________________
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
