python-ldap-dev

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

[<mi...@st...>]

HI!

David, please take note of this!

What was the rationale of having this macro in constants.c?
What are "reversibles" in this context?

#define add_int_r(d, name)                                              \
         {                                                               \
             long v = LDAP_##name;                                       \
             PyObject *i = PyInt_FromLong( v );                          \
             PyObject *s = PyString_FromString( #name );                 \
             PyDict_SetItem( d, s, s );                                  \
             PyDict_SetItem( reverse, i, s );                            \
             PyDict_SetItem( forward, s, i );                            \
             Py_DECREF(i);                                               \
             Py_DECREF(s);                                               \
             /* printf("%s -> %ld\n", #name, v );  */                    \
         }

[..]

         /* reversibles */

         zero = PyInt_FromLong( 0 );
         PyDict_SetItem( reverse, zero, Py_None );
         Py_DECREF( zero );

         add_int_r(d,RES_BIND);
         add_int_r(d,RES_SEARCH_ENTRY);
         add_int_r(d,RES_SEARCH_RESULT);
         add_int_r(d,RES_MODIFY);
         add_int_r(d,RES_ADD);
         add_int_r(d,RES_DELETE);
         add_int_r(d,RES_MODRDN);
         add_int_r(d,RES_COMPARE);
         add_int(d,RES_ANY);

         add_int_r(d,RES_SEARCH_REFERENCE);
         add_int_r(d,RES_EXTENDED);
         add_int_r(d,RES_UNSOLICITED);

It seems to map some integers from ldap.h to strings with the constant's 
name. For some unknown reason this does not work with OpenLDAP 2.2 libs 
anymore. E.g. there are integers returned by l_ldap_result() as result type 
and this breaks ldap.async or other code which trys to evaluate the result 
type as string.

I have a working solution without add_int_r() which might be 
backward-compatible if one strictly uses constants. This looks like a good 
compromise for me.

Any comments?

Ciao, Michael.

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

[<mi...@st...>]

Michael Str=F6der wrote:
>=20
> I have a working solution without add_int_r() which might be=20
> backward-compatible if one strictly uses constants. This looks like a=20
> good compromise for me.

I've committed this solution to CVS. Please test if your code using=20
python-ldap makes use of result types (e.g. see source of ldap.async).

Ciao, Michael.

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

[David L. <d...@ad...>]

Michael

The reason for having l_ldap_result convert from int to string, was purely
that it made the returned tuple easier to inspect visually.
Also, the reason for the introduction of 'same-named' symbols
(ldap.RES_BIND="RES_BIND") is to catch typos (cf the __slots__ hack, or
X11's resource string constants starting with 'XtN'). The forward and
reverse dictionaries are artifacts of this strange system.

You are right that removing the translation and changing the 'constants' to
numbers would break anyone's code that used string literals.
I have no idea why OpenLDAP2.2 breaks it now.

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. Then, because there is no need to have
special strings in the result, you could change all the RES_ constants to be
integers and that would much better match ldap.h. Backward-compat with
people's code that used string literals would still be a problem, but
wouldn't be hard to fix. Further, with this instance-instead-of-tuple
approach, an opportunity arises for metaclasses and mixins etc. It could
make OO-zealots very happy :)

d

----- Original Message -----
From: "Michael Ströder" <mi...@st...>
To: <pyt...@li...>
Sent: Thursday, March 11, 2004 3:57 AM
Subject: Problem with OpenLDAP 2.2: Macro add_int_r() in constants.c?!?


> HI!
>
> David, please take note of this!
>
> What was the rationale of having this macro in constants.c?
> What are "reversibles" in this context?
>
> #define add_int_r(d, name)                                              \
>          {                                                               \
>              long v = LDAP_##name;                                       \
>              PyObject *i = PyInt_FromLong( v );                          \
>              PyObject *s = PyString_FromString( #name );                 \
>              PyDict_SetItem( d, s, s );                                  \
>              PyDict_SetItem( reverse, i, s );                            \
>              PyDict_SetItem( forward, s, i );                            \
>              Py_DECREF(i);                                               \
>              Py_DECREF(s);                                               \
>              /* printf("%s -> %ld\n", #name, v );  */                    \
>          }
>
> [..]
>
>          /* reversibles */
>
>          zero = PyInt_FromLong( 0 );
>          PyDict_SetItem( reverse, zero, Py_None );
>          Py_DECREF( zero );
>
>          add_int_r(d,RES_BIND);
>          add_int_r(d,RES_SEARCH_ENTRY);
>          add_int_r(d,RES_SEARCH_RESULT);
>          add_int_r(d,RES_MODIFY);
>          add_int_r(d,RES_ADD);
>          add_int_r(d,RES_DELETE);
>          add_int_r(d,RES_MODRDN);
>          add_int_r(d,RES_COMPARE);
>          add_int(d,RES_ANY);
>
>          add_int_r(d,RES_SEARCH_REFERENCE);
>          add_int_r(d,RES_EXTENDED);
>          add_int_r(d,RES_UNSOLICITED);
>
> It seems to map some integers from ldap.h to strings with the constant's
> name. For some unknown reason this does not work with OpenLDAP 2.2 libs
> anymore. E.g. there are integers returned by l_ldap_result() as result
type
> and this breaks ldap.async or other code which trys to evaluate the result
> type as string.
>
> I have a working solution without add_int_r() which might be
> backward-compatible if one strictly uses constants. This looks like a good
> compromise for me.
>
> Any comments?
>
> Ciao, Michael.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>

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

[<mi...@st...>]

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.