[python-ldap] ANN: python-ldap 2.5.2
michael at stroeder.com
Mon Nov 20 18:55:53 EST 2017
John Dennis wrote:
> On 11/20/2017 02:23 PM, Michael Ströder wrote:
>> Hmm. The main obstacle for back-porting pyldap is that I'd like to keep
>> python-ldap binary-only and still let the calling app do the Unicode
>> decode/encode stuff if needed. It seems you're endorsing the opposite
> Why? What is your rationale for that?
> It seems entirely appropriate and user friendly for the binding to
> perform the UTF-8 encode/decode.
As Raphaël also pointed out it's a bit more complicated.
Even in my higher-level code I often e.g. treat DNs or similar values
opaque which are internally sent or received through LDAP controls. In
this case decoding and re-encoding is unnecessary and error-prone. Many
code parts have to be changed. Code passing in or out to the
higher-level module should be Unicode if appropriate (if needed).
> Asking users to understand *and* never forget to apply all
> endcode/decode operations when handling LDAP data is large opportunity
> for errors as has been shown to be prevalent in the existing binding
> usage. Plus, doing the endcode/decode in the binding is super easy. So
> why not if it's easy and has been shown to greatly eliminate errors?
Hmm, please don't get it wrong. But your comment sounds a bit that
you're mostly handling simple searches with strings going in and out
which are known to be UTF-8. But that's not the case in general.
IMO there should be a low-level, bytes-only module like python-ldap and
the "user-friendly" part (for whatever definition of role "user") should
be done in higher-level wrapper modules.
Another point of view: Would you expect a low-level DNS module to handle
Unicode decoding/encoding? Note that despite hostname conventions in the
DNS protocol labels are OctetString.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
More information about the python-ldap