Re: [xml-bindings]libxml2.nodeWrap

On Thu, Feb 26, 2004 at 12:23:31PM -0500, Marc-Antoine Parent wrote:
> Good day!
> I did point out a while ago that there was a problem with CDATA 
> elements in the nodeWrap function. As it turns out, there is a problem 
> with the whole nodeWrap function, which uses the node's name instead of 
> type, not to mention a few other crippling typos. (diffs below)

  Okay, I applied the changes. The patch didn't applied directly (
not sent as attachment and reversed), but it was easy to do manually.

> Also of interest, if I parse a document, I find that  a few nodes (the 
> DTD declarations) are given to me as the wrong Python class to start 
> with. In other words, if I walk over a document with the following 
> code:
> def show(node):
>     newNode = libxml2.nodeWrap(node._o)
>     if newNode.__class__ != node.__class__:
>         print node.type,node.__class__,newNode.__class__
> I find the following mistyped node types:
> entity_decl libxml2.xmlNode libxml2.xmlEntity
> elem_decl libxml2.xmlNode libxml2.xmlElement
> attribute_decl libxml2.xmlNode libxml2.xmlAttribute

  Hum, can you provide a self contained test case and bugzilla it ?

> I do not know what part of the python binding code creates the original 
> xmlNodes, but clearly there is a problem elsewhere in the code.
> I do get the correct subclass for
> attribute (libxml2.xmlAttr)
> document_xml (libxml2.xmlDoc)
> namespace (libxml2.xmlNs)
> All of the other types (cdata ,comment, element, entity_ref, pi, text) 
> also end up as libxml2.xmlNode, as intended.
> (Why are there not python subclasses for those types, by the way?)

  Well because at the C level the data structures are the same and there
was no need to separate them at the Python level.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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