[XML-SIG] Announcing PyXPath 1.2

[Martin v. Loewis]

Hi Jeremy,

Thanks for your comments. I'll study them in detail later.

> Should the constants be defined where they are used?

I think the DOM is proof that this is not desirable. If constants are
defined in an interface, applications have to know the names of the
interface implementation classes. In the case of the DOM, we just
solved this by providing xml.dom.Node in the package, which *just*
contains the node type constants. That, in turn, required to rename
4DOM's Node.py to FtNode.

> The expression types in the Expr interface,
> axis specifier types in the AxisSpecifier interface,
> node test types in the NodeTest interface,

To get a true separation of interface and implementation, the base
package would need to provide xml.xpath.Expr.RELATIVE_LOCATION_PATH -
how else are applications supposed to refer to these constants?

> A benefit from this would be helping to avoiding circular imports.
> 
> xml.xpath -> (the parser) -> ExprFactory -> (constants from xml.xpath)
> Sure imports could be done in the functions, but top level imports offer
> some speed improvements.  Slight, but every little bit helps.

I don't see how it would remove circular imports: the constants would
still live in xml.xpath.__init__.py. Also, circular imports are not a
problem per se: __init__ just needs to guarantee that the constants
(and anything else provided to implementations) is defined before
anything originating from an implementation is imported.

Perhaps it would be even better *not* to provide
xml.xpath.{parser|factory}, but to require the user to explicitly
specify the implementation to use:

from xml.xpath.FtFactory import factory
from xml.xpath.PyXPath import parser

or, with the "pick an arbitrary one" API

from xml.xpath.anyfactory import factory
from xml.xpath.anyparser import parser

Regards,
Martin