[XML-SIG] XPath's reliance on id()
Mon, 11 Mar 2002 17:38:17 +0100
PyXML's XPath implementation sometimes calls Util.SortDocOrder, which in
turn tries to push DOM nodes into a hashtable by using the id() function on
the nodes, to do some indexing. This relies on something beyond the DOM,
and causes me trouble with Zope's ParsedXML's DOM, which due to various reasons
makes the use of id() directly unreliable.
Now, it's hard to see how to make this code work without some hashing,
so we seem to have to rely on *something*. But can't we make it
use __hash__ instead of using id? I think I can make this work for
ParsedXML (in fact I tried and at least it's not giving any errors).
This means the following needs to happen:
* all DOMs that expect to work with PyXML's xpath need to define
__hash__(). In the simplest case this simply does an id() on the
* we need to alter the code in xpath/Util.py so as not to rely on
id() anymore but to use the node objects as hash keys directly.
Does this seem like a plan people can live with? If so I volunteer in
going in and do this for PyXML.
Hmm.. I just thought of a possible spanner in the works. ParsedXML works
by having proxy DOM objects that refer to the real underlying DOM node.
If the underlying node defines __hash__ and the proxy objects forward
to it, will Util.py's index dictionary still work properly?
Or should I use hash() directly to go around that issue?