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

[Michael Pechal]

Stefan,

Thank you for your prompt reply.  I found the Epydoc URL
(http://codespeak.net/lxml/dev/api/lxml.objectify-module.html) which
provided more information.  I did not see a direct link to here from the
lxml page or perhaps I missed it?

I have provided a few responses below.

Regards,
Michael

-----Original Message-----
From: lxml-dev-bounces at codespeak.net
[mailto:lxml-dev-bounces at codespeak.net] On Behalf Of Stefan Behnel
Sent: Monday, October 08, 2007 2:47 AM
To: Michael Pechal
Cc: lxml-dev at codespeak.net
Subject: Re: [lxml-dev] Issues with objectify.ObjectifiedElement:
assignment, attribute handling, and documentation

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.

[MP] I suppose I was being a little lazy here.  I am retrofitting an
existing cPickle implementation with custom data classes.  Only a few
parts of the data model will require the attributes, so it won't be too
painful to create sub-elements for what I am now trying to store as
attributes.


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

[MP]  Thanks for the clarification.  I should have stated
"objectify.IntElement".


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

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

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

[MP] Very nice!



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

[MP] Ah, I see.  I misunderstood the various formats for the _xsi
attribute.  I should have used _xsi='int' or 'short'.  Thanks for the
clarification.
>>> e = objectify.DataElement(1, _xsi='integer')
>>> type(e.pyval)
<type 'long'>
>>> e = objectify.DataElement(1, _xsi='int')
>>> type(e.pyval)
<type 'int'>
>>> e = objectify.DataElement(1, _xsi='short')
>>> type(e.pyval)
<type '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.

[MP] With the correct _xsi attribute, annotate() correctly restores the
pytype attribute to 'int'.
>>> e = objectify.DataElement(1, _xsi='int')
>>> e.items()
[('{http://codespeak.net/lxml/objectify/pytype}pytype', 'int'),
('{http://www.w3.org/2001/XMLSchema-instance}type', 'short')]
>>> objectify.deannotate(e)
>>> e.items()
[]
>>> objectify.annotate(e)
>>> e.items()
[('{http://codespeak.net/lxml/objectify/pytype}pytype', 'int')]



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

[MP] I would just clarify that the etree.parse() call returns
etree._ElementTree type, while the getroot() call returns
objectify.ObjectifyElement type for direct use.  This took about ten
minutes to undercover, so it was not a huge problem.  I just like to
jump in and run with examples to see how far I can get before I have to
roll-up my sleeves and review the details of a new module. :)  I will
spend some time reviewing the etree documentation as well.

>>> parser = etree.XMLParser(remove_blank_text=True)
>>> lookup = objectify.ObjectifyElementClassLookup()
>>> parser.setElementClassLookup(lookup)
>>> tree = etree.parse('codec.xml', parser)
>>> type(tree)
<type 'etree._ElementTree'>
>>> tree.reg_config
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'etree._ElementTree' object has no attribute
'reg_config'
>>> root = tree.getroot()
>>> type(root)
<type 'objectify.ObjectifiedElement'>
>>> root.reg_config
<Element reg_config at cc7ea0>


This email and any attachments thereto may contain private, confidential, 
and privileged material for the sole use of the intended recipient. Any 
review, copying, or distribution of this email (or any attachments thereto) 
by others is strictly prohibited. If you are not the intended recipient, 
please contact the sender immediately and permanently delete the original 
and any copies of this email and any attachments thereto.