[lxml-dev] objectify E-factory does not handle unicode text

[Stefan Behnel]

Stefan Behnel wrote:
>> Another issue with E-factory is that it currently does not have support for
>> the custom objectify classes that you can add with the PyType mechanisms: E.g.
>> I'm using datetime and decimal additions, which leads to
>>
>>>>> import decimal
>>>>> DEC = objectify.E.decimal
>>>>> DEC(decimal.Decimal(0))
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>   File "/data/pydev/hjoukl/LXML/lxml-1.3/build/lib.solaris-2.8-sun4u-2.4/lxml/builder.py", line 43, in <lambda>
>>     return lambda *args, **kwargs: func(tag, *args, **kwargs)
>>   File "/data/pydev/hjoukl/LXML/lxml-1.3/build/lib.solaris-2.8-sun4u-2.4/lxml/builder.py", line 175, in __call__
>>     raise TypeError("bad argument type: %r" % item)
>> TypeError: bad argument type: Decimal("0")
>>
>> So I'd have to add decimal.decimal into objectify.E._typemap. The nicest way to handle this would be PyType.register() doing it for me, but
>> PyType uses type names rather than type objects for its purposes. Maybe the easiest thing is to instrument ElementMaker with its own register/unregister(<type>) methods and well-document it?
> 
> No, one registry should be enough. Even with names, you can always check
> globals() in the PyType registry. Maybe we should even feed the typemap in
> ElementMaker.__init__ from the PyType registry (and just update objectify.E
> when the registry is changed).

Ah, I guess the problem here is that your external types are not in the
module's globals(). Maybe we could extend the data element classes with a
non-public function that converts a value to a string. Would that fit here?
Note that the Element proxy is already created when the text value is updated,
that's like your _setText() case.

Stefan