Message 180366 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	scoder
Recipients	scoder
Date	2013-01-22.07:16:24
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>
In-reply-to

Content
There's a bug originally report for lxml that also applies to ElementTree: https://github.com/lxml/lxml/issues/95 Passing different namespace mappings into the Element.find*() methods will always reuse the first one due to incorrect caching based only on the literal path, not all parameters. My fix is here: https://github.com/lxml/lxml/commit/8bafbdc13ffb4fb8436eda01594780aac4735528 The lookup performance regression when a namespace mapping is passed (sorting etc.) is acceptable as most use cases won't pass any namespaces anyway, so this is a problem that rarely shows in practice.

There's a bug originally report for lxml that also applies to ElementTree:

https://github.com/lxml/lxml/issues/95

Passing different namespace mappings into the Element.find*() methods will always reuse the first one due to incorrect caching based only on the literal path, not all parameters. My fix is here:

https://github.com/lxml/lxml/commit/8bafbdc13ffb4fb8436eda01594780aac4735528

The lookup performance regression when a namespace mapping is passed (sorting etc.) is acceptable as most use cases won't pass any namespaces anyway, so this is a problem that rarely shows in practice.

History
Date	User	Action	Args
2013-01-22 07:16:24	scoder	set	recipients: + scoder
2013-01-22 07:16:24	scoder	set	messageid: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>
2013-01-22 07:16:24	scoder	link	issue17011 messages
2013-01-22 07:16:24	scoder	create