[python-ldap] Supporting syncrepl (and fixing LDAPObject.results{, 2, 3, 4})

[Petr Viktorin]

On 15. 03. 22 11:26, Ondřej Kuzník wrote:
> Hi all,
> this has been on my list for a while and definitely needs fixing
> for 4.0. The way we parse results is broken, we cannot process
> intermediate responses properly and the results are n-tuples where n
> often depends on the arguments passed to .result4(). Also the way
> LDAPmessage_to_python works, we lose the order messages actually came
> in, that's a no-no for syncrepl at the very least. And .result() callers
> shouldn't get an exception when a non-zero result message is received,
> losing all other messages in the process forever.
> 
> This needs work on all levels of the module:
> - C code needs to expose a new results interface that returns everything
>    in a common interface with common fields like result, message,
>    references, OID, controls etc. where appropriate.
> - by the time they are returned from the Python side, each response should
>    be an instance of LDAPMessage subclass as appropriate with controls,
>    intermediate and extended messages fully decoded if a decoder is
>    available. It will be possible to check the result code and raise an
>    appropriate exception as usual for each message derived from
>    LDAPResult.
> 
> This is a stepping stone towards a similar overhaul of the request API,
> removing some of the distinction between the _s and non-_s variants as
> well as resiter eventually enabling asyncio compatible operation (see
> my asyncio wrapper[0] for an example how the API could look like).
> Of course, it will be fun to make sure we don't break any backwards
> compatibility in the 3.x interface for others.
> 
> Comments on the design and volunteers to help with this are welcome.

FWIW, the general way to upgrade from tuples to objects with attributes 
in C is PyStructSequence [1], the implementation of os.stat_result or 
sys.float_info. Unlike a Python namedtuple, it allows named-only 
attributes. So the result() return value could continue to be a 
backwards-compatible 2-tuple but have all other relevant attributes as well.


> [0]. https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/ldap_wrapper.py
[1] https://docs.python.org/3/c-api/tuple.html#c.PyStructSequence_NewType