[XML-SIG] pyexpat v. xml.parsers.expat ?

[Fred L. Drake, Jr.]

Paul writes:
 > Well, according to your proposals nobody is going to reference pyexpat (or
 > anything in it) directly anyhow. You can remap it however you want in your
 > wrapper.

  The structure is still interesting.

 > I was trying to follow os.path but obviously it doesn't work exactly the
 > same way os.path does. The overall goal was to avoid having a confused

  The reason the os.path thing actually works is that os is imported
before user code ever gets control -- when site imports os, os can do
what it needs to do.  If it wasn't import before user code is run, it
wouldn't work.  To import a submodule in the general case, the parent
must be a package -- the directory and __init__.py{,c,o} file *must*
exist.
  Tedious and somewhat annoying, but that's the current mechanism.

 > top-level environment. I think that dir() is one of Python's great
 > features and overloaded top-level environment destroy its utility.

  I don't disagree with your goal of keeping the interface clean --
the fact that it was a module was throwing me off.  When I revised the
documentation to use xml.parsers.expat, I decided not to document it
as a module, but just say it's an object.  (Hmm, now I can think of
another change that's required in the docs regarding this.)
  Sometimes it would be really nice to have an instance that doesn't
have a class for things like this.  ;)


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member