aspineux at gmail.com
Fri Jul 20 14:52:34 CEST 2007
First I'm not upset by anything.
You are responsible to maintain the package in an healthy state.
This also your responsibility to add or remove some features and then
to maintain them.
Thanks for doing that.
As you have suggested, I made a class wrapper that keep both code as
independent as possible, and I'm happy with that.
Anyway I'have some comment about your answerer ...
On 7/19/07, Michael Ströder <michael at stroeder.com> wrote:
> 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.
Unicode string in python are made in a way that let the developer use them
in a complete transparent way. If the libraries are respecting this
the developer can exchange data from different sources (user input,
SQL, ldap ...)
without never making any conversion.
The problem is strings are also used for binary storage and LDAP don't
between both usage (no charset and unicode types like in SQL), only
the developer know
and can make the conversion.
> 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.
Today passing unicode argument to ldap functions raise an exception, then
no accidents is possible :-)
On the other side, with unicode support, things could accidentally
work as expected.
But this is only speculation about witch inconvenient is the worst.
> > 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
I have no website today :-(
Please use the last version in attachment.
> Ciao, Michael.
aspineux gmail com
May the sources be with you
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10591 bytes
Desc: not available
More information about the python-ldap