[lxml-dev] lxml 2.3alpha1 released
Hi all, I'm happy to announce the first alpha release of lxml 2.3. This is *not* a production-ready release, and there will be further fixes and changes before the final 2.3 release. Therefore, it is not the default version on PyPI but only available via "easy_install lxml==2.3alpha1" and from here: http://pypi.python.org/pypi/lxml/2.3alpha1 http://codespeak.net/lxml/dev/ The main reasons for this release are: There hasn't been a release for too long; there were too many changes in the meantime, including various bug fixes; I'd like to make it easier for users to benefit from those improvements and to report bugs and unexpected changes that get in their way. Note that not all reported bugs in the tracker that I'd like to fix for 2.3 are closed with this alpha, but I hope that a couple of others will make it before the final release. If you think that your Very Important Bug hasn't received enough interest so far, consider adding a comment to the bug tracker. ("fix this bug!" may not be enough ;) Major new features in this release include better compatibility with ElementTree 1.3 (which will be in the Python 3.2 standard library), ISO-Schematron support and various usability fixes for XSLT and XPath. The (IMHO) most important bug fix is the hardening of the API against potential crashes due to badly initialised wrapper objects. It is the clear intention for the future development to make lxml safer to use and hard to crash. I'm also planning to offer commercial (paid) support for lxml's further development, so if you really need a new feature or can't wait for a bug to get fixed, you may consider paying me to do it for you. Important notice: This does *not* mean that lxml is going non-free in any way, or that its OpenSource development is endangered. Lxml will continue to ship its complete source code under the liberal BSD license, and any (generally interesting) paid changes will become part of the mainline distribution. It just means that there will be a way for users to financially support my work on the project and to invest resources into targeted work that they can't (or don't want to) do themselves. This release was built using revision "c71560698d0d" of the cython-closures development branch (pre-0.13). A final Cython 0.13 is expected for early July, which will be the base for the final lxml 2.3 release. ... and I'm pretty sure this is the longest release announcement I've ever written. ;) Have fun, Stefan Here's the complete post-2.2.6 changelog for this release: 2.3alpha1 (2010-06-19) ====================== Features added -------------- * Keyword argument ``namespaces`` in ``lxml.cssselect.CSSSelector()`` to pass a prefix-to-namespace mapping for the selector. * New function ``lxml.etree.register_namespace(prefix, uri)`` that globally registers a namespace prefix for a namespace that newly created Elements in that namespace will use automatically. Follows ElementTree 1.3. * Support 'unicode' string name as encoding parameter in ``tostring()``, following ElementTree 1.3. * Support 'c14n' serialisation method in ``ElementTree.write()`` and ``tostring()``, following ElementTree 1.3. * The ElementPath expression syntax (``el.find*()``) was extended to match the upcoming ElementTree 1.3 that will ship in the standard library of Python 3.2/2.7. This includes extended support for predicates as well as namespace prefixes (as known from XPath). * During regular XPath evaluation, various ESXLT functions are available within their namespace when using libxslt 1.1.26 or later. * Support passing a readily configured logger instance into ``PyErrorLog``, instead of a logger name. * On serialisation, the new ``doctype`` parameter can be used to override the DOCTYPE (internal subset) of the document. * New parameter ``output_parent`` to ``XSLTExtension.apply_templates()`` to append the resulting content directly to an output element. * ``XSLTExtension.process_children()`` to process the content of the XSLT extension element itself. * ISO-Schematron support based on the de-facto Schematron reference 'skeleton implementation'. * XSLT objects now take XPath object as ``__call__`` stylesheet parameters. * Enable path caching in ElementPath (``el.find*()``) to avoid parsing overhead. * Setting the value of a namespaced attribute always uses a prefixed namespace instead of the default namespace even if both declare the same namespace URI. This avoids serialisation problems when an attribute from a default namespace is set on an element from a different namespace. * XSLT extension elements: support for XSLT context nodes other than elements: document root, comments, processing instructions. * Support for strings (in addition to Elements) in node-sets returned by extension functions. * Forms that lack an ``action`` attribute default to the base URL of the document on submit. * XPath attribute result strings have an ``attrname`` property. * Namespace URIs get validated against RFC 3986 at the API level (required by the XML namespace specification). * Target parsers show their target object in the ``.target`` property (compatible with ElementTree). Bugs fixed ---------- * API is hardened against invalid proxy instances to prevent crashes due to incorrectly instantiated Element instances. * Prevent crash when instantiating ``CommentBase`` and friends. * Export ElementTree compatible XML parser class as ``XMLTreeBuilder``, as it is called in ET 1.2. * ObjectifiedDataElements in lxml.objectify were not hashable. They now use the hash value of the underlying Python value (string, number, etc.) to which they compare equal. * Parsing broken fragments in lxml.html could fail if the fragment contained an orphaned closing '</div>' tag. * Using XSLT extension elements around the root of the output document crashed. * ``lxml.cssselect`` did not distinguish between ``x[attr="val"]`` and ``x [attr="val"]`` (with a space). The latter now matches the attribute independent of the element. * Rewriting multiple links inside of HTML text content could end up replacing unrelated content as replacements could impact the reported position of subsequent matches. Modifications are now simplified by letting the ``iterlinks()`` generator in ``lxml.html`` return links in reversed order if they appear inside the same text node. Thus, replacements and link-internal modifications no longer change the position of links reported afterwards. * The ``.value`` attribute of ``textarea`` elements in lxml.html did not represent the complete raw value (including child tags etc.). It now serialises the complete content on read and replaces the complete content by a string on write. * Target parser didn't call ``.close()`` on the target object if parsing failed. Now it is guaranteed that ``.close()`` will be called after parsing, regardless of the outcome. Other changes ------------- * Official support for Python 3.1.2 and later. * Static MS Windows builds can now download their dependencies themselves. * ``Element.attrib`` no longer uses a cyclic reference back to its Element object. It therefore no longer requires the garbage collector to clean up. * Static builds include libiconv, in addition to libxml2 and libxslt.
On 2010-06-19, at 3:52 AM, Stefan Behnel wrote:
it is not the default version on PyPI but only available via "easy_install lxml==2.3alpha1"
Hmm, the thing is ... even if a release is "hidden" in PyPI, easy_install (specifically setuptools.package_index, which is what PyPM uses as well) and pip will find it. $ bin/easy_install lxml Searching for lxml Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.3alpha1 Downloading http://pypi.python.org/packages/source/l/lxml/lxml-2.3alpha1.tar.gz [...] If this is not intended, please do not upload alpha releases to PyPI. -srid
Sridhar Ratnakumar, 21.06.2010 19:15:
On 2010-06-19, at 3:52 AM, Stefan Behnel wrote:
it is not the default version on PyPI but only available via "easy_install lxml==2.3alpha1"
Hmm, the thing is ... even if a release is "hidden" in PyPI, easy_install (specifically setuptools.package_index, which is what PyPM uses as well) and pip will find it.
Ah, and I was wondering why the downloads were firing up that quickly. ;)
$ bin/easy_install lxml Searching for lxml Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.3alpha1 Downloading http://pypi.python.org/packages/source/l/lxml/lxml-2.3alpha1.tar.gz [...]
If this is not intended, please do not upload alpha releases to PyPI.
It's not intended. I'd consider it a bug in PyPI (and right another one in setuptools). The "simple" page shows all sorts of files that make absolute no sense. Just because a URL appears somewhere on a page about an outdated and disabled software version doesn't mean tools like setuptools should get their nose bumped into it. And I can't see a way to prevent entries from appearing on that page. I guess the only way to prevent automatic installation for now is to remove the file from PyPI, which, I guess, will disable easy_install support completely... Stefan
On 2010-06-21, at 11:01 AM, Stefan Behnel wrote:
$ bin/easy_install lxml Searching for lxml Reading http://pypi.python.org/simple/lxml/ Reading http://codespeak.net/lxml Best match: lxml 2.3alpha1 Downloading http://pypi.python.org/packages/source/l/lxml/lxml-2.3alpha1.tar.gz [...]
If this is not intended, please do not upload alpha releases to PyPI.
It's not intended. I'd consider it a bug in PyPI (and right another one in setuptools). The "simple" page shows all sorts of files that make absolute no sense. Just because a URL appears somewhere on a page about an outdated and disabled software version doesn't mean tools like setuptools should get their nose bumped into it. And I can't see a way to prevent entries from appearing on that page.
This was discussed before http://www.mail-archive.com/catalog-sig@python.org/msg01511.html ... but no resolution was taken.
I guess the only way to prevent automatic installation for now is to remove the file from PyPI, which, I guess, will disable easy_install support completely...
Yes, it will also disable pip/PyPM support. Perhaps you can poke Martin in distutils-sig@ about this bug in PyPI. :-) -srid
participants (2)
-
Sridhar Ratnakumar
-
Stefan Behnel