Fred L. Drake
Fred L. Drake, Jr." <firstname.lastname@example.org
Fri, 21 May 1999 17:55:32 -0400 (EDT)
Paul Prescod writes:
> Why? easySax allows the person to move to another parser if they want.
> It's an abstraction over xmllib that gives them more freedom of choice.
I'm fine with this.
> In fact, I'd like to see easySax put on top of sgmlop and promoted as the
> "standard" Python/XML integration for Python 1.6. Maybe by Python 2 we
This presents a very real problem: xmllib is already standard and
documented, and therefore "in use". Deprecating it is a problem
because people will need to update their code for what will probably
be a mostly minimal difference (for existing code). Updating what's
currently xml.parsers.xmllib to the documented xmllib interface and
using that as the standard xmllib would be a big improvement,
esp. with sgmlop in the core.
That's not to say an additional API can't be added, but a second
event-based interface is not necessarily a good idea. Perhaps a
compromise API can be created which extends the xmllib interface with
the pi_*(), ppi_*(), and text_*() methods? Extending the existing
interface is not a problem as far as I can tell. It can still be
highly efficient, especially if we allow handle_data() to be
> So how about that? easySax and sgmlop in Python 1.6. xmllib's interface is
> deprecated. Additional parsers and handlers can be downloaded as part of
> the xml sig distribution?
As long as the base easySAX can accept arbitrary backends I'm still
happy. There's no reason not to allow the xmllib.XMLParser to support
arbitrary backends as well, with the default being the current
implementation (or something compatible).
Fred L. Drake, Jr. <email@example.com>
Corporation for National Research Initiatives