Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?

[Michael Ströder]

David Leonard wrote:
> 
> The reason for having l_ldap_result convert from int to string, was purely
> that it made the returned tuple easier to inspect visually.

I already dropped it. Bring your CVS dir in sync.

> You are right that removing the translation and changing the 'constants' to
> numbers would break anyone's code that used string literals.

Well, this seems a minor issue to me. I fixed mine. Using constants is also 
more robust against typos.

> An alternate (and more high-level) approach would be to create a Result
> class, and have l_ldap_result return instances of Result (instead of a
> tuple). Using __getitem__ you could make it backward-compatible with the
> extant tuples. Also, using __repr__ you could have Result instances make
> sense when printed interactively.

I already thought about changing all this mess with l_ldap_result() and 
define different classes for the result types. I could do lots of these 
things in ldap.ldapobject.LDAPObject wrapper class but maintaining the C 
code is a major PITA for me.

We should strip down l_ldap_result() to be a really dumb wrapper around 
OpenLDAP's ldap_result() and do the backward-compatible rest in 
LDAPObject.result().

> you could change all the RES_ constants to be
> integers and that would much better match ldap.h.

Already done. Since the C code is still a big mystery to me and it highly 
depends on API decisions of the OpenLDAP folks I'm generally trying to make 
it as lean as possible stripping everything away and eventually reimplement 
it in the Python wrapper modules.

Ciao, Michael.