[lxml-dev] objectify factories

[Stefan Behnel]

jholg at gmx.de wrote:
>> Given the current behaviour of _setElementValue(), I'd say it should just
>> go and annotate everything it produces.
> 
> Meaning an additional TypedElementMaker, right? I think it is actually nice to have the not-annotating ElementMaker as a choice.

Why? I would actually be surprised if elements generated by the objectify.E
factory returned different value types than when creating a tree 'by hand'.


>>> Also, I think it might make sense to have a PT() factory after all, just
>> to add the possibility to hand in attributes:
>>>
>>>>>> root.x = 3
>>>>>> root.x.set("foo", "bar")
>>>>>> # shortcut
>>>>>> root.x = PT(3, foo="bar")
>> DataElement can add attributes for you.
> 
> Yes it does but not the same way. DataElement() always uses the literal of the RVAL to infer the type, if not explicitly given, i.e. it does not make use of the python type of an RVAL. PT() otoh does work just like the new __setattr__/_setElementValue. Maybe modify DataElement() instead of introducing PT(), then?

+1 for having the same behaviour everywhere.

Stefan