[lxml-dev] [objectify] Typed E-factory for objectify, PT DataElement()-wrapper

[Stefan Behnel]

jholg at gmx.de wrote:
> due to (seemingly) pressing needs of my users, I propose a change of
> ObjectifiedElement '.'-operator subelement-setting (the _setElementValue
> function, to be exact) behaviour, possibly configurable as a module setup.
> The proposed change is to auto-add the python type() of the RVAL of an
> assignment as a py:pytype attribute. This is much what you would use the
> proposed-below PT convenience function for, with current behaviour.
> 
> Current behaviour:
> >>> root = objectify.Element("root")
> >>> root.s = "0003"
> >>> print objectify.dump(root)
> root = None [ObjectifiedElement]
>     s = 3 [IntElement]
> 
> Proposed behaviour (switchable):
> >>> root = objectify.Element("root")
> >>> root.s = "0003"
> >>> print objectify.dump(root)
> root = None [ObjectifiedElement]
>     s = '0003' [StringElement]
>       * py:pytype = 'str'

Hmmm, this makes sense at first sight, but I'll have to think this through to
figure out the implications.

I'm not all together happy with the attribute type business today, as it keeps
people from generating 'clean' XML. Ok, you can run deannotate() on trees
before you serialise, but that might mean that objectify could behave
differently the next time you parse it. So it's somewhat quirky either way:
live with the artifacts or live with surprises. Sounds like the first is a lot
better, though. :)


> I am well aware that this
> * auto-adds an attribute to an Element, where you now need to tell this explicitly, e.g. by using DataElement()

We already do that in a couple of places now, so it wouldn't add much
ugliness. It would even make the type behaviour less surprising - you get out
what you put in. I agree that this actually helps users.

We're talking about 2.0 behaviour here, though.


> In addition, I still propose what I posted before ;-):

Right, I'll look at that also. We really need a bug tracker for lxml...

Stefan