Hi all, this has been in the queue for quite a while: the global Namespace() class lookup will go away in lxml 2.0, although it will be possible to write backwards compatible code. In lxml 1.x, the namespace class lookup was configured using the global Namespace() factory. This was easy, but it was also an application wide setup:

...

...

ns = etree.Namespace("http://my/namespace") ns["mytag"] = MyElementClass

The lookup itself was then configured through the ElementNamespaceClassLookup class, which (starting with lxml 1.2) was a parser local setup:

...

...

lookup = etree.ElementNamespaceClassLookup() parser = etree.XMLParser() parser.setElementClassLookup(lookup)

In lxml 2.0, the namespace registry will become local to the lookup instance. Consequently, the new setup will look like this:

...

...

lookup = etree.ElementNamespaceClassLookup() parser = etree.XMLParser() parser.setElementClassLookup(lookup)

...

...

ns = lookup.get_namespace("http://my/namespace") ns["mytag"] = MyElementClass

Not a big difference, but this still has the huge benefit that the namespace registry can now be different for different parsers, i.e. different modules using lxml can now have their own registry without having to fear any interference with other modules or parts of an application. This means that all Element class lookup schemes are now parser local. As the usage itself does not change, it is easy to adapt existing code so that it runs with lxml 2.0 while still supporting lxml 1.2/3 (at least, it was easy enough to adapt the unit tests in lxml...). All you have to do is set the same lookup instance for all parsers you use (note that the initial setup is already required today) and replace the occurrences of calls to etree.Namespace by the "get_namespace" method of that lookup instance. I believe that this simple change is easy enough to work around for existing code, so it will not have a big impact here. However, the advantage of removing the global setup and thus supporting independent configurations for different parts of an application (and third party libs) outweighs this overhead considerably. Have fun, Stefan