[XML-SIG] Extending the xml package

[Greg Stein]

I saw that you already checked this in :-(

This solution is definitely sub-optimal. Specifically:

  sys.modules['xml'].__name__ != 'xml'

Monkeying around with sys.modules is a clue that you are depending on
"magic" in the import and module-handling mechanisms. Given some of the
import stuff that people are trying to do (various packaging and archiving
and stuff), this is dangerous stuff.

Here is my suggestion again (with some merging of your code):

xml.__init__:

__version__ = 1
if __name__ == 'xml':
    try:
        import _xmlplus
    except ImportError:
        pass
    else:
        _xmlplus._setup_package(__version__)


_xmlplus.__init__:

def _setup_package(version):
    import xml   # note: available, but empty

    from _xmlplus.parsers import xmlproc, xmlsre
    xml.parsers.xmlproc = xmlproc
    xml.parsers.xmlsre = xmlsre
    # etc


The above code relies on nothing "magic" in the module or import handling.
The _xmlplus package can extend the xml package in any way that it sees fit.
This solution is much more robust in the fact of "funny" import/packaging
scenarios. _xmlplus can override stuff in the xml package and it can extend
it. But it doesn't override *everything* which your suggested code does.

Cheers,
-g

On Thu, Jul 27, 2000 at 01:31:22AM -0400, Fred L. Drake, Jr. wrote:
> 
>   As promised, I brought up the package extension issue at today's
> PythonLabs meeting.  We decided that there are two interesting cases
> for package importing involved here.
>   The first is package extension -- allowing one package to extend
> another.  We basically agreed that the Java model got this right, with
> the issue of multiple __init__ modules being a serious problem for
> Python (it's not clear what the right way to deal with multiple
> __init__ modules; you want to execute all of them, and the current
> implementation doesn't lend itself to this).  This is the approach
> we've discussed here before.
>   Another possibility is providing an extended replacement for the
> standard package.  This doesn't sound like it makes sense given that
> using the same name creates order dependencies for sys.path, and the
> current setup would be wrong for overriding a standard package with a
> package installed in site-packages or a user's or application's
> private library.
>   However, this actually appears to be the most reasonable if we want
> to be able to include bug fixes in the "enhanced" version of the
> package, and doesn't require weird hacking on distutils.  It does
> require that the package that can be overridden in this way be written
> to support this.
>   Here's how to do it:
>   Deploy the "xml" package in the standard library.  Create an
> "_xmlplus" package (PyXML) which provides all of the facilities from
> the standard library and any extensions.  The "_xmlplus" package can
> be treated as any other package with distutils.
>   In the __init__.py for the "xml" package, include the following
> code:
> 
> ------------------------------------------------------------
> if __name__ == "xml":
>     try:
>         import _xmlplus
>     except ImportError:
>         pass
>     else:
>         import sys
>         sys.modules[__name__] = _xmlplus
> ------------------------------------------------------------
> 
>   Yes, this works.
>   The leading test for __name__ is useful to allow the same file to be
> used for both the xml and _xmlplus packages.
>   The PyXML package (providing _xmlplus) could continue to be the
> leading-edge development package with all the bells and whistles, and
> portions adopted into the standard library could be updated before a
> Python release.
>   Guido also suggested looking at the version-handling code from Pmw,
> but I don't know how valuable that would be.
>   Comments?
> 
> 
>   -Fred
> 
> -- 
> Fred L. Drake, Jr.  <fdrake at beopen.com>
> BeOpen PythonLabs Team Member
> 
> 
> _______________________________________________
> XML-SIG maillist  -  XML-SIG@python.org
> http://www.python.org/mailman/listinfo/xml-sig

-- 
Greg Stein, http://www.lyra.org/