Re: [xml] Support for Python

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

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

     * 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

  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 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

_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?


[ gary inauspicious org ][ GnuPG 85A8F78B ][ ]

Thanks for the suggestions and ideas.

  - Dave

Dave Kuhlman
dkuhlman rexx com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]