Hi all, I know, breaking compatibility is a serious topic, so I'm putting this here for an open discussion. This change would only impact code that uses the namespace class lookup to supply custom element classes to lxml.etree. Other code would continue to work. Currently, lxml.etree does namespace lookup for custom element classes by default. This has been the case in the 0.9 and 1.0 series. Starting with lxml 1.1, etree will support not only custom classes, but also custom lookup schemes for these classes. It includes a generic fallback mechanism from one lookup scheme to another if the first one fails. This means that the default support for namespace class lookup is becoming redundant, as it is also supported by a public class that provides the namespace lookup scheme. Also, the current scheme does not support a fallback other than the default element class, so code that wants to use the namespace lookup with a different fallback is still required to re-register both. To remove this redundancy, to speed up the default setup if namespace classes are /not/ used and (above all) to make the lookup API more accessible, I would like to remove the default for namespace lookup and replace it by the simplest possible mechanism that always returns the normal element classes. If namespace lookup support is needed, something like the following code would be required at setup time: from lxml import etree try: lookup = etree.ElementNamespaceClassLookup() except AttributeError: # lxml >= 0.9 and < 1.1 supports this by default pass else: # lxml >= 1.1 requires an explicit setup etree.setElementClassLookup(lookup) This code block is backwards compatible with lxml 0.9 and lxml 1.0, so new code that requires namespace class lookup could continue to support lxml from version 0.9 on, while older code that uses namespace classes would have to be updated with the above code block to support lxml 1.1 and later. Doing this switch *now* makes the above code pretty short, later changes would require version checking and the like. One of the main reasons for this change is that I would like to make the lookup mechanism explict and visible. It is a global property that impacts the entire library. Users who do not need to install their own custom classes should not be bothered with it, i.e. should be able to ignore the lookup API, the Namespace class registry, etc. For those who need a different mechanism, I believe that the current default does not make it visible enough that (for example) the functionality of the "Namespace" class registry is disabled if you select a different class lookup mechanism. So the new custom class support would work like this: * if no custom classes are used, no configuration is needed * any support for custom classes requires setting up a lookup scheme * changing the default class is done by creating and setting a default lookup scheme based on the new default classes * using the namespace lookup requires setting the ns lookup scheme, which then enables lookups based on the global Namespace registry * setting a per-parser lookup scheme enables delegation to the specific lookup registered with a parser, which in turn can deploy any of the available schemes and defaults to using the normal classes I'm also considering to replicate the Namespace registry locally in the ElementNamespaceClassLookup class. This would allow things like a per-parser namespace registry and the like. I think removing the default would also help in getting this cleaner. I'm really interested in hearing opinions on this. I think the above compatibility code makes the switch trivial to do, but I would like to hear if there are other impacts of this change that I might not have thought of. Stefan