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

Stefan Behnel stefan_ml at behnel.de
Wed Jul 4 15:59:17 CEST 2007


jholg at gmx.de wrote:
>> Stefan Behnel wrote:
>>>> 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.
> 
> What one actually does for registration is 
> 
> datetimeType = PyType("datetime", parseDatetime, DatetimeElement)
> datetimeType.register()
> 
> just like objectify does for the standard builtin types. I think that
> PyType.register()/unregister() should update E._typemap; the problem
> here is that register() does not really know about the Python type, just
> a name, a check function and the ObjectifiedDataElement class; this is also nice because it is so versatile.
> 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?

Stefan


More information about the lxml-dev mailing list