unicode value
Michael Ströder
michael at stroeder.com
Thu Jul 19 15:38:56 CEST 2007
Alain,
Alain Spineux wrote:
>
> When investigating about python and unicode, I read somewhere (in a PEP
> I thing) that python functions should accept and manage unicode string
> as well as normal string.
Without knowing the PEP (reference?) I guess this affects functions
which takes a string as an argument and process it directly returning a
result. In context of python-ldap this would be directly applicable to
the functions in modules ldap.dn and ldap.filter.
The basic problem here is that for the sake of backward-compability to
LDAPv2 the charset has to be passed around either. That's what I'm doing
in web2ldap.
> Of course if these strings could contains user
> readable characters.
Let's call that "textual strings".
> Anyway I see 2 solutions
>
> 1. Let result() return non unicode strings. _HERE_ The user know all
> returned
> strings are normal strings utf-8 encoded and he can do the encoding
> himself. A helper function doing the job for the result structure
> should be welcome.
>
> 2. Do the conversion regarding the info provided in the query, as my
> source sample does.
>
> I answer now some of your previous comment:
>
>> > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ]
>> > to convert only 'givenName' and 'sn'
>
>> But then you will not gain much! Still the application has to know which
>> attributes have to be converted. => It's not worth hiding the conversion
>> within python-ldap.
>
> I don't really hide the conversion, because the user has to request it using
> unicode field name.
I don't like this approach. The type of the attribute names is causing a
type conversion side-effect. I don't consider this to be good design and
I guess most Python developers would not expect something like this.
Think about an application accidently passing in Unicode strings but is
not really prepared to get the Unicode/string mix.
> Do you really consider to add the schema processing for unicode
> integration in the future?
Nope. It's up to the application programmer, especially based on whether
LDAPv2 support is still needed for a particular application or not. I
consider python-ldap to be rather a low-level API.
> Keep in mind, none of my code break compatibility with existing application.
Generally I don't want to discourage people to work on something. But
sorry, I won't add your code to python-ldap's Lib/. I hope you're not
upset. My proposal would be to add it under Demo/ so you're work can be
considered to be used by others. Or you can put it on your own web page
(for further development) and I'll put a link to it on
http://python-ldap.sourceforge.net/docs.shtml.
Ciao, Michael.
More information about the python-ldap
mailing list