Re: [xml] Support for Python

[Dave Kuhlman <dkuhlman cutter rexx com>]

On Mon, Jan 28, 2002 at 02:41:48PM +0000, Gary Benson wrote:
> On Fri, 25 Jan 2002, Daniel Veillard wrote:
>
> > On Thu, Jan 24, 2002 at 04:57:39PM -0800, Dave Kuhlman wrote:
> >
> > >      * Because I used SWIG's shadow classes, the doc, nodes, and
> > >        attributes look, from Python's point of view like instances of
> > >        classes. So, walking the DOM tree is very easy and natural.
> >
> >   Sounds a good idea, I need to look at the generated code. Anover way
> > is to make minimal wrappers and build more object oriented classes on
> > top of the raw function, defining the classes at the Python level.
>
> It's a lot nicer defining the classes in Python than in C, and you have 
> the added benefit that it is a lot easier for someone trying to use the 
> library to see how it works.

I should have been a bit more clear about this.  When you ask SWIG
to generate "shadow" classes, which I did, SWIG generates a .py
file with Python classes in it.  So when you do:

> > > doc = p.xmlParseFile('test1.xml')
> > > root = doc.children

you have created an instance of the Python class xmlDoc and an
instance of the Python class xmlNode, each of which hold a
reference to an underlying C object (xmlDoc and xmlNode, defined in
tree.h).

> Also (but don't quote me on this) I'm not sure that you can derive
> subclasses from classes defined in C modules. I was was unable to find a C
> module that exports a class to test however.

I agree with your point.  We need Python classes.  SWIG can
generate them.  We have to decide whether to use them, whether and
how to modify them, etc.

Actually, in Python 2.2, with the new "unification of types and
classes", it is possible to implement _types_ in C that can be
subclassed.  But your point is still valid:  Real classes are
better.

> > >      * One qualification is that the interface is at the level of the
> > >        libxml, so it's a bit low level. For example, a long running
> > >        application would have to call a 'free' method, e.g. xmlFreeDoc,
> > >        which is not something a Python programmer would expect to have to
> > >        do.
> >
> >   Hum, keeping reference counting for xmlDocPtr is nearly impossible,
> > I doubt there is a workaround. Well this need more thinking, the idea
> > of having to call a doc.free() at the end of the processing doesn't sound
> > that bad.
>
> If we write the classes in Python then this is trivial -- call xmlFreeDoc 
> in the XmlDocumentClass's destructor and let Python's garbage collector 
> work out when to do it.

Interesting idea.  Because of your suggestion, I looked at the
generated code.  And, I can modify the SWIG generated code so that
the Python __del__ method in the Doc class will call a C delete
method and I can modify the C delete method so that it calls
xmlFreeDoc.

_But_, I worry about code like the following:

> > > doc = p.xmlParseFile('test1.xml')
> > > root = doc.children
> > > doc = p.xmlParseFile('test1.xml')

Now, root contains a reference to a Python object that contains a
reference to an underlying C object (a libxml node) that has gone
away.  Am I right about this?  If so it seems very dangerous. 
xmlFreeDoc frees the nodes in the doc, too, doesn't it?

> Cheers,
> Gary
>
> [ gary inauspicious org ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

Thanks for the suggestions and ideas.

  - Dave


-- 
Dave Kuhlman
dkuhlman rexx com
http://www.rexx.com/~dkuhlman