[lxml-dev] lxml 1.3 - or 2.0?
Stefan Behnel
stefan_ml at behnel.de
Sun May 27 15:45:38 CEST 2007
Hi all,
I'm currently thinking about what should be changed or fixed for lxml 2.0, a
preliminary list is at the end of TODO.txt. As fixing the entity handling
would visibly change the way parsers behave (more exceptions, stricter
parsing, etc.), maybe this would rather go into that list. This is what I have
for now:
* reformat error log lines, add column number
* always use '<string>' as URL when tree was parsed from string? (can libxml2
handle this?)
* clean up (and remove?) duplicated API for extension functions
* find a way to integrate Schematron (if it's available)
* always use ns-prefixed type names in objectify's ``xsi:type`` attributes
* remove ``findOrBuildNodeNs()`` from C-API (replaced by
findOrBuildNodeNsPrefix)
* lxml.html (Ian?)
* clean support for entities (maybe an Entity element class?)
* follow PEP 8 in API naming (avoidCamelCase in_favour_of_underscores)
The list of trunk changes since 1.2.1 is already pretty long, and there were
some major changes under the hood (even since 1.3beta), e.g. the namespace
cleanup code, XSD type prefixing in objectify, exception messages, etc.
Hence, I'm actually considering to skip the 1.3 release and to rather start
working on 2.0 directly, so that we could have an alpha version soon. Maybe
some more bug fixes could be backported into a 1.2.2 first, so that people can
work with it, but a 1.3 would mean "new features". I would like to have the
freedom to break a few things here in order to make their API cleaner. And
that means 2.0, not 1.3.
Comments?
Stefan
More information about the lxml-dev
mailing list