[XML-SIG] [Fwd: Namespace collision between lib/xml and site-packages/xml]

Mark Favas m.favas@per.dem.csiro.au
Fri, 01 Sep 2000 08:49:17 +0800


This is a multi-part message in MIME format.
--------------52DF9690B2074B5895C6673A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[copy of message sent to python-dev]
-- 
Email  - m.favas@per.dem.csiro.au        Mark C Favas
Phone  - +61 8 9333 6268, 0418 926 074   CSIRO Exploration & Mining
Fax    - +61 8 9383 9891                 Private Bag No 5, Wembley
WGS84  - 31.95 S, 115.80 E               Western Australia 6913
--------------52DF9690B2074B5895C6673A
Content-Type: message/rfc822
Content-Disposition: inline

Message-ID: <39AEDC5B.333F737E@per.dem.csiro.au>
Date: Fri, 01 Sep 2000 06:29:47 +0800
From: Mark Favas <m.favas@per.dem.csiro.au>
Organization: CSIRO Exploration & Mining
X-Mailer: Mozilla 4.75 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: python-dev@python.org, xml-sg@python.org
Subject: Namespace collision between lib/xml and site-packages/xml
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On July 26 I reported that the new xml package in the standard library
collides with and overrides the xml package from the xml-sig that may be
installed in site-packages. This is still the case. The new package does
not have the same functionality as the one in site-packages, and hence
my application (and others relying on similar functionality) gets an
import error. I understood that it was planned that the new library xml
package would check for the site-package version, and transparently hand
over to it if it existed. It's not really an option to remove/rename the
xml package in the std lib, or to break existing xml-based code...

Of course, this might be fixed by 2.0b1, or is it a feature that will be
frozen out <wry smile>?

Fred's response was:
"  I expect we'll be making the package in site-packages an extension
provider for the xml package in the standard library.  I'm planning to
discuss this issue at today's PythonLabs meeting." 
-- 
Mark

--------------52DF9690B2074B5895C6673A--