[XML-SIG] XML in Python 1.6 (PROPOSAL)

[Uche Ogbuji]

> 
> Uche Ogbuji writes:
>  > Unless someone has done substantial work on a driver to create a
>  > DOM from a SAX parser (4DOM's won't do as they aren't up to the
>  > latest Sax2 yet), I'd say we leave this out until Python 1.7.
> 
>   I'm expecting Lars to provide SAX 2 support "out of the box" for
> Python 1.6.

If you are answering about our ability to use 4DOM's Sax2, OK, we could get it 
in line with Lars's latest (not that much is different from our Sax2 draft 
besides the namespace stuff).

But I could also understand your response to indicate that Lars would be 
shipping a DOM builder with SAX2, or am I muddling things up?

>  > I think we should continue to put all XML things in the xml package.  Why 
>  > muddy the waters?  Why can't the PyXML package just know to add its extras 
>  > into the existing xml package?
> 
>   The catch is that *requires* that PyXML either be installed on top
> of the Python distribution (since the xml package can only exist in
> one place in the directory tree), or that it include all the standard
> portions of the xml package.  I'm not real happy with either
> approach.

All approaches seem kludgy to me as well.  I guess I'm not so worried as long 
as whatever tricks we use, the final import for core Python _and_ xml-sig is 
"xml".

>   Another possibility may be to have PyXML provide a package
> "xmlextra" (or whatever), and xml.__init__ can check for it's presence
> and "incorporate" it somehow:
> 
> ------------------------------------------------------------
> try:
>     import xmlextra
> except ImportError:
>     # not present
>     pass
> else:
>     # add new subpackages
>     __path__.append(os.path.dirname(xmlextra.__file__))
>     del xmlextra
> ------------------------------------------------------------
> 
>   There are two problems with this approach:
> 
>   1.  The packages/modules provided by xmlextra are importable by two
>       names: xml.<foo> and xmlextra.<foo>.  I'm not entirely sure how
>       much we should care about this one.

I wouldn't worry about it: we can either not publish the xmlextra package, or 
we can explicitly forbid using it in the docs.

>   2.  Old versions of xmlextra may be installed in a user's (or
>       application's) private area, but a more recent version of
>       Python's standard xml package is installed (with a more recent
>       version of Python).  Again, I'm not sure how relevant this is,
>       but it does offer potential breakage.

This sort of version skew could happen in many situations and I'm not sure we 
should lose sleep over it.

-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +01 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python