[lxml-dev] objectify factories

[jholg at gmx.de]

Hi,

> Stefan Behnel wrote:
> > Regarding the TypedElementMaker, I think that if we write one that is
> adapted
> > to objectify, we should not stop half-way. We should remove the
> "typemap"
> > thing and just use the type inference mechanisms that objectify already
> > provides. You can take a look into that, if you want, otherwise I will
> try to
> > come up with an implementation when I find the time (which may be after
> the
> > release of 2.0alpha1).
> 
> ... or a bit before :)
> 
> This code is what I think might work well for objectify. Any general
> comments
> before I go any further?
> 
> Stefan
> [...]

I finally looked at the new ElementMaker implementation, and it works just fine for me. Attached patch adds tests for it (essentially the very same I already had for the initial implementation), plus some small tests that cover DataElement() "none" vs "NoneType" name compatibility measures.

However, this ElementMaker does not add type annotation, as the TypedElementMaker I proposed at some point did. Question: Do we want/need a TypedElementMaker? I'd say yes, otherwise the E-Factory isn't very useful for someone who wants "strong typing".

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")

What do you say?
Holger

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efactory_none_compat_tests.patch
Type: application/octet-stream
Size: 4738 bytes
Desc: not available
Url : http://codespeak.net/pipermail/lxml-dev/attachments/20070830/0016d779/attachment.obj