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

[Paul]

On Fri, 22 Sep 2000, Fred L. Drake, Jr. wrote:

> 
>   I have a couple of questions about pyexpat.
> 
>   First question:
>   At various points, Guido has commented on the strange name "pyexpat"
> -- he generally doesn't like names with a "py" stuck on the front
> simply because something is written in Python.
>   Does anyone have an objection to renaming pyexpat _expat, and using
> a Python wrapper called xml.parsers.expat?  The wrapper would only
> need to import the existing interface, not wrap it with Python
> classes, which would only slow things down.

If the DLL name is hidden from the user then why not use pyexpat? It has
the virtue that in flat-namespace library environments like Windows,
nobody else is going to make a library with the same name. Whereas _expat
would be perfectly reasonable for a TCL or Perl DLL that also embeds
expat.

>   Second question:
>   I'd also like to understand why the error constants are in a
> sub-module, pyexpat.errors, instead of being in pyexpat itself.
> pyexpat.errors is a strange little module in that you can't import it
> until after you've done an "import pyexpat" -- it probably won't bite
> anyone, but this doesn't really follow the least-surprise principle.

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.

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

 Paul