[lxml-dev] Issues with objectify.ObjectifiedElement: assignment, attribute handling, and documentation

[Stefan Behnel]

Hi,

thanks for sharing your impressions.


Michael Pechal wrote:
> I am new to XML and I have found lxml.objectify to be very useful.  I am
> using XML to store register settings.  I use the register mnemonic as
> the tag.  I use custom attributes to store additional information, such
> as address, description, apply, etc.

This sounds a bit like attribute misuse. If you are not tied to a specific XML
language, consider storing this information in the XML structure rather than
XML attributes, just as you would in a Python object.


> I am also using the _pytype and
> _xsi attributes.  I am using the binary install of lxml 1.3.4 on WinXP
> running Python 2.5.1.
> 
> My main problem is that assigning a new value to an
> objectify.DataElement destroys the existing attribute list.

That's intentional. It's like when you assign a Python value to an object
attribute. The old value will be lost in that case, including all of its own
attributes. Note that I'm not talking about XML at all here, this is plain
Python object behaviour, which is what objectify mimics.


> I thought about subclassing DataElement

DataElement is not a class, it's a factory function. So you can write a
wrapper but you cannot subclass it.


> and then I scanned the SVN
> development change list.  I saw some discussion about preserving _pytype
> or _xsi attributes, but does this include ALL attributes?

No, these two are special (or rather their namespaced XML attributes).


> If so, I will
> proceed with a build from the latest SVN copy.  How stable are dev
> versions?

There are currently two actively maintained branches: the 1.3 branch for the
stable 1.3 series (basically, everything that gets committed here will be in a
future 1.3.x release), and the current trunk for the future 2.0 series, which
is currently in alpha status. This means: some functionallity and some APIs
are not stable yet and there may still be incompatible changes to come if
their value for lxml 2.0 is considered high enough to break current code.

The 2.0 web pages are also online:

http://codespeak.net/lxml/dev/


> Are there automated acceptance tests (unittest) that gate the
> check in?

Sure, check out the test suite that comes with the source distribution. It's
pretty extensive by now.

http://codespeak.net/lxml/build.html#running-the-tests-and-reporting-errors

There is also a benchmarking suite that might be of interest to you.

http://codespeak.net/lxml/performance.html


> I may just use my workaround until 1.3.5 arrives.

No 1.3.x release will ever change the above behaviour, and it won't change for
2.0 either.


> Another issue I noticed is that if I specify _xsi='int', the _pytype
> attribute will be 'long' instead of 'integer', so I am forced to use
> _pytype='integer' for all integer data elements.

You're mixing names here, so I'm not quite sure what exactly you are doing.
Make sure you are distinguishing between Python type names and XSI type names
in your code. In general, XSI types are more accurate, so you might want to
prefer them.

The Python type "long" maps to the XSI type "integer" and various other XSI
types. Only the small XSI integer types like "int" or "short" map to a Python int.


> Also, if you run
> objectify.annonate(), the integer becomes a long type again.  Annotate
> should look to the _xsi or even pyval type.  Has this been fixed?  This
> is not really an issue for me, since I always keep the list annotated.

This has been changed in 2.0, which uses annotations quite a bit more
naturally. The current behaviour in 1.3 will not change, unless it's
considered a bug that should be fixed.


> The objectify API documentation was helpful.  As a new user, I had a few
> problems with save and retrieve from file.

That's because this is done through lxml.etree rather than objectify directly.
You will almost certainly need both to work with objectify anyway, so it's
worth skipping through the lxml.etree tutorial.

That said, the objectify documentation is starting to get rather lengthy.
Maybe we should start focussing it a bit, also towards users that do not know
lxml.etree or ElementTree before looking at objectify.


> I would suggest updating the
> objectify API document to provide a full example of saving to and
> loading from a file.  I have provided a test case from my unittest code
> below that may be useful for the documentation:

Thanks. This is a question of duplicating documentation versus making it
easily accessible. We also use our documentation as doctests, where accessing
files is not as straight forward as it should look.


> Also on the documentation front, there is a failure with help() on the
> objectify module.  :
>
>  >>> help(objectify)
> 
> Traceback (most recent call last):
> TypeError: 'functools.partial' object is not iterable
> 
> Note that help(etree) works fine.

Ah, I wasn't aware of that. However, it seems to be more of a problem in
help() itself rather than objectify. I'll have to investigate this one day or
another...

Stefan