[lxml-dev] new Namespace() registry behaviour for lxml 2.0

[Stefan Behnel]

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