Re: [xml] Support for Python

On Mon, Jan 28, 2002 at 02:32:38PM -0500, Daniel Veillard wrote:
On Mon, Jan 28, 2002 at 10:51:58AM -0800, Dave Kuhlman wrote:
On Mon, Jan 28, 2002 at 02:41:48PM +0000, Gary Benson wrote:
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

  I still haven't been able to get SWIG to work. It does write a c file,
but emits errors on fetaures it doesn't support:
parser.h : Line 236. Function pointers not currently supported (ignored).
parser.h : Line 520. Variable length arguments not supported (ignored).

  And doesn't seem to produce a .py . It produce pydom_wrap.c, which then
compiles and load but I'm unable to load anything :

I think the trick is to add the flag "-shadow" when you run swig. 
Here is the command line that I use:

swig -python -shadow -I/w2/XML/Libxml/libxml2-2.4.13/include/libxml pydom.i

And here is my pydom.i:


%module pydom
#include "xmlmemory.h"
#include "parser.h"
#include "parserInternals.h"
#include "tree.h"
xmlChar * c2x(char * s1)
    return (xmlChar *)s1;
char * x2c(xmlChar * s1)
    return (char *)s1;
xmlChar * c2x(char * s1);
char * x2c(xmlChar * s1);
%include "tree.h"
%include "parser.h"


import pydom
doc = pydom.xmlParseFile("test1.xml")
print 'version: %s' % pydom.x2c(doc.version)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: version

OK. I don't understand this either.  I'm using Python 2.2, but I do
not believe there is anything in it that requires version 2.2.

I tried it with Python 2.1 (after rebuilding the .so with Python
2.1 include files).  My tree walk test runs OK.

  tried version_get which from my reading of the C code should work,
but it fails too ... weird. I have tried with both 1.5 and 2.1 without

SWIG does some "name mangling" (at least when I generate shadow
classes) to keep methods in separate classes unique.  For the
xmlDoc, in my generated code, I believe the function is called

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.

  My current appraoch is to try with SWIG, if it looks really nice
adopt it as is, if not keep the good points and write a generator
based on the interface definition and the SWIG output examples.

Sounds to me that you are saying that SWIG is worth exploring a bit
further.  I agree with that.

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

  Well I would really like to have this portable to both 1.5 and 2.1.

Another good reason for using shadow classes.  We'll have to check
it, but I believe that SWIG generates reasonably conservative code.

  - Dave

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

  Really dangerous. As you pointed out too as soon as Python will loose
a pointer to the root it would then deallocate the full subtree. Too
dangerous to be allowed. I started toying with the idea but as soon
as I tried to build an example I realized it would really make a big problem.
  I don't think we can have garbage collectable xmlDoc, though nearly
every other classes exposed should be garbageable.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine
xml mailing list, project page
xml gnome org

Dave Kuhlman
dkuhlman rexx com

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