python-ldap-dev — discussion among developers

Re: Backward compability older Python versions

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

Deepak Giridharagopal wrote:
 > On Fri, 2005-03-04 at 12:13 +0100, Michael Ströder wrote:
 >
 > Python-ldap works with Python 1.x? The INSTALL doc says that 2.0+ is a
 > prerequisite.

Hmm, the low-level stuff could work with Python 1.x.

 > I ask because the patches I've thrown out there haven't
 > been tested on 1.x...

Nevermind. Many parts of recent python-ldap are not tested with Python 
1.x. And so far nobody complained at all.

Ciao, Michael.

Re: Backward compability older Python versions

[Deepak G. <de...@ar...>]

On Fri, 2005-03-04 at 13:13 +0100, Jens Vagelpohl wrote:
> At the same time I think if you make sure to clearly mark this step 
> (both in the docs ("If you use OL version X you can only use 
> python-ldap version Y") as well as maybe by a new version number scheme 
> (a 2.1 beta series comes to mind)) people should be satisfied. They 
> will still complain, of course ;)

+1 for the "2.1 beta series" suggestion. 

deepak

--
Deepak Giridharagopal

Re: Backward compability older Python versions

[Deepak G. <de...@ar...>]

On Fri, 2005-03-04 at 12:13 +0100, Michael Str=F6der wrote:
> For various reasons it is difficult to support older versions of Python=
.=20
> Especially supporting 1.x is a pain with newer modules written in=20
> Python.=20

Python-ldap works with Python 1.x? The INSTALL doc says that 2.0+ is a
prerequisite. I ask because the patches I've thrown out there haven't
been tested on 1.x...

> Personally I'd like to be drop support for any Python version earlier=20
> than 2.3. This would make it possible to use standard modules like sets=
=20
> and datetime which could make life easier.

+1

Cheers!
deepak

--
Deepak Giridharagopal

Re: Odd error with sasl_interactive_bind_s

[Deepak G. <de...@ar...>]

On Fri, 2005-03-04 at 13:12 +0100, Michael Str=F6der wrote:
> Extension modules are not binary-compatible between media versions of=20
> Python. A module compiled for 2.2 cannot run under Python 2.3 without=20
> being rebuilt.

Hmmm, didn't realize that. I will now wave my magic wand and we'll all
pretend I never sent out that last message. :)

On Fri, 2005-03-04 at 14:29 +0100, Mauro Cicognini wrote:=20
> Moreover, reading the code it appears to me that checking just the mino=
r=20
> version means that as written it will only work within the 2.x branch.=20
> Of course there's no telling what will happen in the time coming, so=20
> this point can be moot, but I would advise for checking the major=20
> version also.

When Python 3000 comes out it will have python-ldap as part of the
standard library and our work will be done! ;) Checking the major
version is trivial to do; I just didn't include it as python-ldap won't
work with 1.x (right?), and I assumed that Python 3.x will require some
major structural changes in the entire codebase. I take your point,
though.

Does anyone have any objections to the attached patch, then?

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Backward compability older Python versions

[Jerome A. <al...@li...>]

On Fri, Mar 04, 2005 at 02:26:11PM +0100, Marc Balmer wrote:
> 
> If "they" still stick to old python versions, then they should probably
> use an old python-ldap as well.  I'd rather like to see a recent 
> python-ldap implementation using a recent python interpreter and recent 
> openldap libraries.
> 
> python-ldap is not only used on Debian Woody so please keep this in mind 
> as well when you'll decide...

No problem.

As far as I'm concerned and if the old versions are still available 
for people who need them, it's +1 as well. 

bye

Jerome Alet

Re: Odd error with sasl_interactive_bind_s

[Mauro C. <mci...@li...>]

Deepak Giridharagopal wrote:

>This patch is a little longer than the previous one, but it works just
>as well. Plus, this way we're doing a run-time check instead of a
>compile-time check. This will let people upgrade to Python 2.3+ without
>having to recompile python-ldap.
>
This would be very well, and a Good Thing, although I beg to differ - on 
Windows a different version of the binaries will always  be needed if 
changing minor version since extensions are linked to the Python DLL 
which is called python22.dll, python23.dll, python24.dll and so on.

Moreover, reading the code it appears to me that checking just the minor 
version means that as written it will only work within the 2.x branch. 
Of course there's no telling what will happen in the time coming, so 
this point can be moot, but I would advise for checking the major 
version also.
After all, there's still a sizable amount of old code around still using 
(actually, requiring!) Python 1.5.2...

Anyway, thanks for the great work, it is doing us a lot of good.

Mauro

Re: Backward compability older Python versions

[Marc B. <ma...@ms...>]

Michael Str=F6der wrote:

>>
>> IIRC Python 2.1.3 is the standard version of Python included in Debian=
=20
>> Woody which is still (unfortunately) the stable Debian release so=20
>> please keep this in mind when you'll decide.=20
>=20
>=20
> Hmm, regarding Linux distributions also the versions of the OpenLDAP=20
> libs come to mind. I'd like drop support for older OpenLDAP libs too to=
=20
> get rid of all the #ifdef's spreaded around in the C source.

If "they" still stick to old python versions, then they should probably
use an old python-ldap as well.  I'd rather like to see a recent=20
python-ldap implementation using a recent python interpreter and recent=20
openldap libraries.

python-ldap is not only used on Debian Woody so please keep this in mind=20
as well when you'll decide...

Regards,
Marc Balmer

mb...@op...

Re: Backward compability older Python versions

[Jens V. <je...@da...>]

On Mar 4, 2005, at 12:13, Michael Str=F6der wrote:

> HI!
>
> For various reasons it is difficult to support older versions of=20
> Python. Especially supporting 1.x is a pain with newer modules written=20=

> in Python. Or there are some subtle changes regarding data types (long=20=

> integers since 2.3 etc.).
>
> Now the question is which versions of Python are still used by the=20
> python-ldap community and should be supported?
>
> Personally I'd like to be drop support for any Python version earlier=20=

> than 2.3. This would make it possible to use standard modules like=20
> sets and datetime which could make life easier.

+1

As with the question of what OpenLDAP versions to support, I believe if=20=

you are clearly marking the change it should be legitimate to go ahead=20=

and do it. People with older OL/Python versions are advised to use=20
previous python-ldap versions.

jens

Re: Backward compability older Python versions

[Jens V. <je...@da...>]

On Mar 4, 2005, at 13:06, Michael Str=F6der wrote:
> Jens Vagelpohl wrote:
>>> Hmm, regarding Linux distributions also the versions of the OpenLDAP=20=

>>> libs come to mind. I'd like drop support for older OpenLDAP libs too=20=

>>> to get rid of all the #ifdef's spreaded around in the C source.
>> Where would you place the "cut-off"? Keep in mind that RH still ships=20=

>> that antiquated 2.0.27 with RH9/RHEL3...
>
> Personally I think we would do Red Hat users a favor with forcing them=20=

> to install 2.2 libs. Note that the OpenLDAP project itself dropped=20
> support for 2.0.x and 2.1.x.

Personally, I *totally* share that opinion. I'm not so certain how well=20=

that would go over with all those people that are too scared/clueless=20
or simply unwilling to go beyond their distro's own packages.

At the same time I think if you make sure to clearly mark this step=20
(both in the docs ("If you use OL version X you can only use=20
python-ldap version Y") as well as maybe by a new version number scheme=20=

(a 2.1 beta series comes to mind)) people should be satisfied. They=20
will still complain, of course ;)

jens

Re: Odd error with sasl_interactive_bind_s

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

Deepak Giridharagopal wrote:
> On Thu, 2005-03-03 at 01:45 +0100, Michael Ströder wrote:
> 
>>No easy way to make it work without another #if ?
> 
> It took me a while to find it (I didn't know it existed!), but there is
> a function, Py_GetVersion,

Sorry, I meant a solution without checking the Python version at all.

> This patch is a little longer than the previous one, but it works just
> as well. Plus, this way we're doing a run-time check instead of a
> compile-time check.

If we have to check the Python version a compile-time check would be the 
preferred solution (see below why).

> This will let people upgrade to Python 2.3+ without
> having to recompile python-ldap.

Extension modules are not binary-compatible between media versions of 
Python. A module compiled for 2.2 cannot run under Python 2.3 without 
being rebuilt.

Ciao, Michael.

Re: Backward compability older Python versions

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

Jens Vagelpohl wrote:
> 
>> Hmm, regarding Linux distributions also the versions of the OpenLDAP 
>> libs come to mind. I'd like drop support for older OpenLDAP libs too 
>> to get rid of all the #ifdef's spreaded around in the C source.
> 
> Where would you place the "cut-off"? Keep in mind that RH still ships 
> that antiquated 2.0.27 with RH9/RHEL3...

Personally I think we would do Red Hat users a favor with forcing them 
to install 2.2 libs. Note that the OpenLDAP project itself dropped 
support for 2.0.x and 2.1.x.

>  If you mean dropping support 
> for OL 1.x, by all means, just do it :)

This already happened long ago...

Ciao, Michael.

Re: Backward compability older Python versions

[Jens V. <je...@da...>]

On Mar 4, 2005, at 12:45, Michael Str=F6der wrote:
>> IIRC Python 2.1.3 is the standard version of Python included in=20
>> Debian Woody which is still (unfortunately) the stable Debian release=20=

>> so please keep this in mind when you'll decide.
>
> Hmm, regarding Linux distributions also the versions of the OpenLDAP=20=

> libs come to mind. I'd like drop support for older OpenLDAP libs too=20=

> to get rid of all the #ifdef's spreaded around in the C source.

Where would you place the "cut-off"? Keep in mind that RH still ships=20
that antiquated 2.0.27 with RH9/RHEL3...  If you mean dropping support=20=

for OL 1.x, by all means, just do it :)

jens

Re: Backward compability older Python versions

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

Jerome Alet wrote:
> 
> On Fri, Mar 04, 2005 at 12:13:11PM +0100, Michael Ströder wrote:
> 
>>Now the question is which versions of Python are still used by the 
>>python-ldap community and should be supported?
>>
> 
> IIRC Python 2.1.3 is the standard version of Python included in 
> Debian Woody which is still (unfortunately) the stable Debian 
> release so please keep this in mind when you'll decide. 

Hmm, regarding Linux distributions also the versions of the OpenLDAP 
libs come to mind. I'd like drop support for older OpenLDAP libs too to 
get rid of all the #ifdef's spreaded around in the C source.

Ciao, Michael.

Backward compability older Python versions

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

HI!

For various reasons it is difficult to support older versions of Python. 
Especially supporting 1.x is a pain with newer modules written in 
Python. Or there are some subtle changes regarding data types (long 
integers since 2.3 etc.).

Now the question is which versions of Python are still used by the 
python-ldap community and should be supported?

Personally I'd like to be drop support for any Python version earlier 
than 2.3. This would make it possible to use standard modules like sets 
and datetime which could make life easier.

Ciao, Michael.

Re: Odd error with sasl_interactive_bind_s

[Deepak G. <de...@ar...>]

On Thu, 2005-03-03 at 01:45 +0100, Michael Str=F6der wrote:
> No easy way to make it work without another #if ?

It took me a while to find it (I didn't know it existed!), but there is
a function, Py_GetVersion, that will give you a version string (similar
to sys.version). The third character is always the minor version number,
so it looks like we can use that as an alternative to the #if.

This patch is a little longer than the previous one, but it works just
as well. Plus, this way we're doing a run-time check instead of a
compile-time check. This will let people upgrade to Python 2.3+ without
having to recompile python-ldap.

I've attached the patch for posterity's sake, but I've gone ahead and
commited the change to CVS.

Good suggestion, Michael. :)

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Odd error with sasl_interactive_bind_s

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

Deepak Giridharagopal wrote:
> 
> Upon further research, it looks like in Python 2.3 (and later) the "I"
> flag will *either* convert the argument to a long *or* an unsigned int.
> In previous versions of Python, "I" will attempt to always convert to a
> long (resulting in the TypeError).
> [..]
> So I've (slightly) re-worked the patch to examine what version of Python
> is being used and react accordingly.

No easy way to make it work without another #if ?
Please commit your patch.

Ciao, Michael.

Re: Odd error with sasl_interactive_bind_s

[Deepak G. <de...@ar...>]

On Wed, 2005-03-02 at 14:11 -0600, Deepak Giridharagopal wrote:
> The 'sasl_flags' variable is declared as an unsigned int, but it looks
> like we're trying to convert it using the "I" flag, which is meant to
> convert longs. Replacing that "I" with "i" tells Python to convert that
> argument to an int (rather than a long), and it seems to do the trick.

Upon further research, it looks like in Python 2.3 (and later) the "I"
flag will *either* convert the argument to a long *or* an unsigned int.
In previous versions of Python, "I" will attempt to always convert to a
long (resulting in the TypeError).

I guess this definitively solves the mystery as to why the bug doesn't
occur in 2.3 and above...

So I've (slightly) re-worked the patch to examine what version of Python
is being used and react accordingly.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Odd error with sasl_interactive_bind_s

[David H. <dh...@vt...>]

Deepak,

Thank you for the patch and the explanation--I was working my way towards 
that, but it would have taken a bit longer to poinpoint it...  ;)

The patch works perfectly and my SASL EXTERNAL bind works as expected. 

Thanks again for the help.

dave

On Wednesday 02 March 2005 15:11, Deepak Giridharagopal wrote:
> Hi, Dave!
>
> I've reproduced your bug, and I've attached a patch that fixes the
> problem. It might interest you to know that this bug doesn't affect more
> recent versions of Python, for what that's worth. :)
>
> The long answer:
>
> On Wed, 2005-03-02 at 12:30 -0500, David Hawes wrote:
> > Traceback (most recent call last):
> >   File "sasl_bind.py", line 69, in ?
> >     l.sasl_interactive_bind_s("", sasl_auth)
> >   File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 196,
> > in sasl_interactive_bind_s    return
> > self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clie
> >ntctrls ,sasl_flags)
> >  File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line
> > 94, in _ldap_call
> >  result = func(*args,**kwargs)
> > TypeError: argument 5 must be impossible<bad format char>, not int
>
> Eek! This looks like a bug in the C code. The function that throws this
> error is PyArg_ParseTuple, a C function bundled with Python that takes
> Python objects and converts them to vanilla C-types.
>
> The offending bit looks to be lines 648-649 in LDAPObject.c:
>
> if (!PyArg_ParseTuple(args, "sOOOI", &who, &SASLObject, &serverctrls,
> &clientctrls, &sasl_flags ))
>     return NULL;
>
> The 'sasl_flags' variable is declared as an unsigned int, but it looks
> like we're trying to convert it using the "I" flag, which is meant to
> convert longs. Replacing that "I" with "i" tells Python to convert that
> argument to an int (rather than a long), and it seems to do the trick.
>
> More info on these arcane conversion flags (for the curious):
> http://docs.python.org/api/arg-parsing.html
>
> Don't you just love C programming? :)
>
> The fix makes Python 2.1.3 work again, and the fix doesn't appear to
> break anything for more recent versions of Python (which, as I said,
> don't seem to suffer from the problem).
>
> Can you try the patch and let me know if it fixes things for you?
> Thanks, Dave!
>
> Cheers!
> deepak
>
> --
> Deepak Giridharagopal
> Applied Research Laboratories
> University of Texas at Austin

Re: Odd error with sasl_interactive_bind_s

[Deepak G. <de...@ar...>]

Hi, Dave! 

I've reproduced your bug, and I've attached a patch that fixes the
problem. It might interest you to know that this bug doesn't affect more
recent versions of Python, for what that's worth. :)

The long answer:

On Wed, 2005-03-02 at 12:30 -0500, David Hawes wrote:
> Traceback (most recent call last):
>   File "sasl_bind.py", line 69, in ?
>     l.sasl_interactive_bind_s("", sasl_auth)
>   File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 196, in
> sasl_interactive_bind_s    return
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clientctrls
> ,sasl_flags)  
>  File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line
> 94, in _ldap_call    
>  result = func(*args,**kwargs)
> TypeError: argument 5 must be impossible<bad format char>, not int

Eek! This looks like a bug in the C code. The function that throws this
error is PyArg_ParseTuple, a C function bundled with Python that takes
Python objects and converts them to vanilla C-types.

The offending bit looks to be lines 648-649 in LDAPObject.c:

if (!PyArg_ParseTuple(args, "sOOOI", &who, &SASLObject, &serverctrls,
&clientctrls, &sasl_flags ))
    return NULL;

The 'sasl_flags' variable is declared as an unsigned int, but it looks
like we're trying to convert it using the "I" flag, which is meant to
convert longs. Replacing that "I" with "i" tells Python to convert that
argument to an int (rather than a long), and it seems to do the trick.

More info on these arcane conversion flags (for the curious):
http://docs.python.org/api/arg-parsing.html

Don't you just love C programming? :)

The fix makes Python 2.1.3 work again, and the fix doesn't appear to
break anything for more recent versions of Python (which, as I said,
don't seem to suffer from the problem).

Can you try the patch and let me know if it fixes things for you?
Thanks, Dave!

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Odd error with sasl_interactive_bind_s

[David H. <dh...@vt...>]

I am attempting to connect to a directory using SASL EXTERNAL with Python (my 
version, from Debian packages, is 2.1.3) and python-ldap-2.0.6.  With both my 
code and the python-ldap-2.0.6/Demo/sasl_bind.py example, I get the following 
exception:

Traceback (most recent call last):
  File "sasl_bind.py", line 69, in ?
    l.sasl_interactive_bind_s("", sasl_auth)
  File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line 196, in
sasl_interactive_bind_s    return
self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,serverctrls,clientctrls
,sasl_flags)  
 File "/usr/lib/python2.1/site-packages/ldap/ldapobject.py", line
94, in _ldap_call    
 result = func(*args,**kwargs)
TypeError: argument 5 must be impossible<bad format char>, not int

Argument 5 is sasl_flags, which seems to be ldap.SASL_QUIET by default.  The 
TypeError output changes when I send sasl_interactive_bind_s different values 
for the sasl_flags argument. 

python-ldap is linked against OpenLDAP-2.2.23 (compiled with SSL and SASL 
support), and ldap.TLS_AVAIL and ldap.SASL_AVAIL both have 1 as their value.  
The OpenLDAP tools work as expected.  python-ldap works as expected when not 
using SASL.  

Has anyone seen similar errors?  What can I try to fix these errors?

Thanks for the help,

dave

Please review and test preliminary support for LDAP controls

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

Dear python-ldap users!

Thanks to the contributions of Deepak Giridharagopal, there's now 
preliminary support for LDAP controls in python-ldap.

Up to now the application has to do the BER encoding itself with the 
help of a third-party module. But looking at Demo/ldapcontrols.py and 
sub-module ldap.controls should give you an idea how it's supposed to work.

Anyway I'd appreciate every one's feedback whether the modifications in 
class LDAPControl and the sub-module ldap.controls seems suitable. So 
please bring your CVS working dir in sync and test. Thanks!

Ciao, Michael.

Re: Seg fault with ldap.get_option(ldap.OPT_SERVER_CONTROLS)

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

Deepak Giridharagopal wrote:
> On Tue, 2005-03-01 at 20:41 +0100, Michael Ströder wrote:
> 
>>I have problems using ldap.get_option(ldap.OPT_SERVER_CONTROLS):
>>
>>$ python2.4 -c "import ldap;ldap.get_option(ldap.OPT_SERVER_CONTROLS)"
>>Segmentation fault
> 
> I found it...there was one spot where I forgot to check to make sure a
> pointer wasn't NULL before I messed with it.

Thanks for the quick fix. Seems to work.

> Also, as an aside, I noticed that in the CVS head the setup.py file
> doesn't include the new ldapcontrol.c file in its list of files to be
> compiled.

Already noticed that. Please sync your CVS and test.

Ciao, Michael.

Seg fault with ldap.get_option(ldap.OPT_SERVER_CONTROLS)

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

Michael Ströder wrote:
> Deepak Giridharagopal wrote:
>  >
>  > Regarding your suggestions, I've attached a new patch (I diff'ed
>  > against the cvs HEAD).
> 
> Thanks again for contributing! Committed to CVS.

I have problems using ldap.get_option(ldap.OPT_SERVER_CONTROLS):

$ python2.4 -c "import ldap;ldap.get_option(ldap.OPT_SERVER_CONTROLS)"
Segmentation fault

Any clue? I'm not a C programmer so I can't tell where the bug lies.

Ciao, Michael.

Re: Seg fault with ldap.get_option(ldap.OPT_SERVER_CONTROLS)

[Deepak G. <de...@ar...>]

On Tue, 2005-03-01 at 20:41 +0100, Michael Str=F6der wrote:
> I have problems using ldap.get_option(ldap.OPT_SERVER_CONTROLS):
>=20
> $ python2.4 -c "import ldap;ldap.get_option(ldap.OPT_SERVER_CONTROLS)"
> Segmentation fault
>=20
> Any clue? I'm not a C programmer so I can't tell where the bug lies.

I found it...there was one spot where I forgot to check to make sure a
pointer wasn't NULL before I messed with it. Embarrassing! :) It's a
2-line fix, and I've attached the patch.

Maybe we should start throwing together some simple tests and throw them
into Tests/Lib/ldap/test_ldapcontrols.py or the like?

Also, as an aside, I noticed that in the CVS head the setup.py file
doesn't include the new ldapcontrol.c file in its list of files to be
compiled. This (a 1-line change) is also in the patch.

Cheers!
deepak

--
Deepak Giridharagopal
Applied Research Laboratories
University of Texas at Austin

Re: Implementation of LDAPControls

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

Deepak Giridharagopal wrote:
 >
 > Regarding your suggestions, I've attached a new patch (I diff'ed
 > against the cvs HEAD).

Thanks again for contributing! Committed to CVS.

 >>One thing I wonder about is whether it's possible to send a control
 >>where the control value is absent (e.g. by passing None as control
 >>value)? See RFC3296 chapter 3 for an example (ManageDsaIT Control).
 >
 > Done!
 > (Before, an error would have been thrown. Now, 'None' is permitted.)

Now I can start re-implementing LDAPObject.manage_dsa_it()...

Ciao, Michael.