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

[Stefan Behnel]

Hi Holger,

jholg at gmx.de wrote:
>>> What about simply adding an optional argument python_type where one can
>> supply the actual python type/class the custom element class does mimic?
>>
>> Well, all you'd really need is a conversion to a string, so, given such a
>> type
>> would Do The Right Thing for __str__, that would work. But then, if str()
>> did
>> the right thing, we could just as well use the existing behaviour of the E
>> factory and just extend typemap to also check for the type /name/, not
>> only
>> the type itself. Maybe that's the way to go?
> 
> You mean by using a customized typemap that uses additional(typename,
> <function>) entries and a get() method that also tries to lookup by
> typename? The convention then being that the typenames one uses in the
> PyType registry must correspond to the actual python type name he models,
> if he wants to make use of objectify.E for custom DataElements. Sounds
> reasonable.

Here is a patch that (I think) might be a way to solve this problem. The idea
is to use a custom class instead of the typemap dictionary and have it fall
back to the PyType registry. If your type does not support a simple str()
conversion, you can pass a conversion function as an additional argument to
PyType() when registering your type.

It's currently untested, so please play with it if you think it's the right
approach.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: objectify-data-type-support-in-elementmaker-class.patch
Type: text/x-diff
Size: 7015 bytes
Desc: not available
Url : http://codespeak.net/pipermail/lxml-dev/attachments/20070704/60b1ba59/attachment-0001.bin