[lxml-dev] objectify factories

[jholg at gmx.de]

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

But it does not add the type annotation attribute to an element, so:

>>> root = E.root(E.x("3"))
>>> print objectify.dump(root)
root = None [ObjectifiedElement]
    x = 3 [IntElement]
>>> 

although "3" is not an integer. Much the same what we discussed regarding DataElement() / PT() behaviour.

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

I'm about to change DataElement to use the new _setElementValue semantics.

Holger
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser