Hi, just noticed that this seems to have been lost entirely:
Hi,
And I think I've found another thing that could be changed: The DataElement() does not treat None arguments the way normal direct assignment does, setting xsi:nil="true". Instead it returns this:
root.n = DataElement(None) print root root = None [ObjectifiedElement] n = None [NoneElement] * py:pytype = 'none'
Find attached a patch that:
- changes the above to apply xsi:nil="true" for None value arguments
- lets DataElement() graciously handle ObjectifiedDataElement arguments, keeping their attributes intact, if not overridden by the DataElement() args. This also reuses existing xsi:type or py:pytype information, unless _pytype and/or _xsi are provided as parameters to DataElement()
Previously, DataElement() cut off all attributes if given an ObjectifiedDataElement instance.
- Type-checks the _value against the given type hint:
objectify.DataElement(273.34, _xsi="int") Traceback (most recent call last): File "<stdin>", line 1, in ? File "objectify.pyx", line 1742, in objectify.DataElement ValueError: invalid literal for int(): 273.34
You will run into the error anyway - sooner or later - when accessing the .pyval in any way, so why not during instantiation.
Tests are included for the described behaviour.
Additionally, I've revamped some of the tests I provided earlier and split them up: More but smaller test methods now.
Please try it out, if any of the DataElement changes are not ok I can also send only the split-up tests, of course.
Or am I missing something? Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger