[python-ldap] ANN: python-ldap 2.5.2

[Petr Viktorin]

On 11/21/2017 11:31 AM, Michael Ströder wrote:
> Petr Viktorin wrote:
>> That's a wrong assumption on your side. We all agree here that attribute
>> *values* should, at the python-ldap level, always be byte strings.
>> [..]
>> Now, the question is about DNs, attribute names, and other data
>> specified as UTF-8.
> 
> But what about the very specific values in extended controls and their
> direct use for further LDAP operations? AFAICS there's no work done in
> pyldap for this.

Right. In pyldap, in all cases where attribute values are to be used as 
text, they need to be decoded first – whether they be names of people, 
descriptions, or, yes, attribute names.

Porting any project to Python 3 involves deciding what is text and what 
is bytes, and changing appropriately. Almost always, some need to 
encode/decode will leak to the applications – you can't really get away 
from that.
We decided the text/bytes boundary, based both on the specs and on the 
needs of real-world projects that build on top of the library. Using the 
result feels that one is working with the language (Python 3), rather 
than against it.

> Frankly I'm really upset that you changed the API while keep the module
> name space just because RedHat was too lazy to adjust own code. This is
> already causing conflicts with distro packages. The role of RedHat in
> this story is not really appealing.

Well, not everyone around the form, including the original author, is 
from Red Hat.
Feel free to accuse me (who agreed with keeping the namespace, so we 
could continue using python-ldap for the cases where it can be used, 
i.e. in python2) or the FreeIPA project (who are the ones "lazy" to 
adjust imports), but who these developers work for is quite irrelevant 
in this case.
Or blame Red Hat, if you want to blame it. But if you want a discussion, 
explanations, or other points of view, it'll be better to talk to the 
specific people.

> Personally I'm considering forking python-ldap into a separate name
> space to keep my own stuff working (with adapted import statements).

That would be sad. We always wanted to contribute the pyldap changes 
back into python-ldap, when possible; this was even one of the major 
reasons for keeping the same import name.
Before you go and fork, can we talk about other possible ways out? We do 
want to help the project, not hurt it – but we're really struggling to 
see the best way for us to do that.


-- 
Petr Viktorin