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

[jholg at gmx.de]

Hi,

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

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()
* in a sense maybe means some loss of symmetry, considering adding content throught the objectify API vs. parsing from an XML file or string

However, my users just can't seem to grasp the notion of "assignment only cares about RVAL literals, and type-lookup happens on element-access by type-guessing". Especially, they seem to have trouble with situations like this:
>>> root = objectify.Element("root")
>>> root.comment = "this is my 500. comment"
>>> print objectify.dump(root)
root = None [ObjectifiedElement]
    comment = 'this is my 500. comment' [StringElement]
>>> root.comment = root.comment.pyval[11:14]
>>> print objectify.dump(root)
root = None [ObjectifiedElement]
    comment = 500 [IntElement]
>>> 

where you cut some parts out of a string and might then get this presented as an IntElement, due to the int-able literal.

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

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

> Hi,
> 
> attached patch (against trunk)
> 
> * adds a typed E-factory (called T-factory)
> * inserts NoneType into the E-factory/T-factory typemap
> * adds the PT() (="PyTyped(<arg>)) convenience function that is a thin
> wrapper uses the argument value's type to set the pytype
> * provides unittests for E-factory, T-factory and PT()
> * fixes DataElement() to care for some previously-unhandled corner cases
> concerning None and/or _pytype "none"
> 
> Despite of what I previously said ;-) I now think it would be better to
> rename "none" to "NoneType", to use the same name as the Python builtin
> original. While it is a longer name I seriously doubt you need to actually use
> it explicitly very often. 
> By convention, the PyType name should match the Python builtin type name;
> then both the T-factory and the PT() function can work smoothly (the only
> thing special-cased is the Python type name "unicode" with gets substituted
> by "str").
> 
> Therefore, the patch also changes "none" to "NoneType" in objectify and
> the objectify tests/doctests.
> 
> I'd really like to see the PT() function go into the 1.3 series, too.
> 
> Please take a look, I can come up with some documentation if you like it.
> 
> Holger

Holger
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail