python-ldap-dev — discussion among developers

Re: CVS: python-ldap

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

Jacek Konieczny wrote:
> 
> Additionaly:
> 
> l.get_option(ldap.OPT_ERROR_NUMBER)
>         instead of
> l.errno
> 
> l.get_option(ldap.OPT_ERROR_STRING)
>         instead of
> l.error
> 
> l.get_option(ldap.OPT_MATCHED_DN)
>         instead of
> l.matched

Removed from where? These should be class attributes of LDAPError
exception instances.

Ciao, Michael.

Re: CVS: python-ldap

[Jacek K. <ja...@bn...>]

On Wed, Nov 14, 2001 at 05:34:05PM +0100, Michael Str=F6der wrote:
> Jacek Konieczny wrote:
> >=20
> > Log message:
> > - setattr() removed, getattr() made minimal
>=20
> Can you shortly describe what this exactly means now? I lost track
> of what get_options()/set_options() is used for at the moment.
It is used for everything that ldap_set_option() in C API is used for.
It replaces some attributes of LDAPObject, which have been removed.

Sou you should use now:

l.set_option(ldap.OPT_PROTOCOL_VERSION,3)
        instead of
l.version=3D3

l.set_option(ldap.OPT_DEREF,1)
        instead of
l.deref=3D1

l.set_option(ldap.OPT_REFERRALS,1)
        instead of
l.referrals=3D3

l.set_option(ldap.OPT_RESTART,1)
        instead of
l.restart=3D1

l.set_option(ldap.OPT_TIMELIMIT,10)
        instead of
l.timelimit=3D10

l.set_option(ldap.OPT_SIZELIMIT,100)
        instead of
l.sizelimit=3D100

The same about reading the attribute and l.get_option().

Additionaly:

l.get_option(ldap.OPT_ERROR_NUMBER)
        instead of
l.errno

l.get_option(ldap.OPT_ERROR_STRING)
        instead of
l.error

l.get_option(ldap.OPT_MATCHED_DN)
        instead of
l.matched

I don't know what some of them do, but this are attributes I have
removed.

> How about you completing/updating the new example script
> Demo/initialize.py ? You can commit the few lines without testing
> and I will test it against my locally installed OpenLDAP 2 server.
I have done this before I got this mail :-)

Greets,
        Jacek

Re: CVS: python-ldap

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

Jacek Konieczny wrote:
> 
> Log message:
> - setattr() removed, getattr() made minimal

Can you shortly describe what this exactly means now? I lost track
of what get_options()/set_options() is used for at the moment.

How about you completing/updating the new example script
Demo/initialize.py ? You can commit the few lines without testing
and I will test it against my locally installed OpenLDAP 2 server.

Ciao, Michael.

CIDict.c

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

David Leonard wrote:
> 
> Modified files:
>         Modules        : CIDict.c
> 
> Log message:
> some old fixes to cidict, useful if it ever gets enabled again

I'd suggest to simply throw CIDict.c away. It's far from being
something complete and can be more easily implemented in Python
based on UserDict.UserDict.

Ciao, Michael.

Re: ldap.set_option() ready

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

Joe Little wrote:
> 
> It seems that to date, the python-ldap API has mirrored that of the
> c-API, but also provided an LDAP object wrapper.
> 
> I think is correct as well as ideal for us to support both the
> set_option() method in the direct API, but for object-oriented purposes
> provide an internal mechanism that calls the set_option using set_attr
> and get_attr syntax.

Since experience of the last months shows that most people on this
list don't like to muck out old C code I'd prefer to keep it as lean
as possible.

It's trivial to write a Python object wrapper around it which maps
set_option() to __setattr__().

Ciao, Michael.

Re: Documenting python-ldap

[David L. <dav...@it...>]

On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:

> Hi,
> I made some basic docstrings for functions I had implemented, but they
> are not perfect. And there is no docs for them in Doc/libldap.tex.
> I don't thing my english is good enough to do the documentation, but
> maybe there is someone here who would like to do this...

It is sufficient at this stage to edit the documentation and write
"To Be Documented" where the documentation should go :) i think your
english is fine

Another approach to documentation is to write simple, commented examples
and leave them in the Demo directory

> The other problem is, that OpenLDAP API has hardly any documentation :-(

yes it seems not to have progressed much since the days of Umich man pages.
Maybe everyone who should be writing documentation is instead making
money by writing books about it? :)

d
-- 
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Re: ldap.set_option() ready

[Joe L. <jl...@ee...>]

I just wanted to butt in with my opinion here.

It seems that to date, the python-ldap API has mirrored that of the=20
c-API, but also provided an LDAP object wrapper.

I think is correct as well as ideal for us to support both the=20
set_option() method in the direct API, but for object-oriented purposes=20=

provide an internal mechanism that calls the set_option using set_attr=20=

and get_attr syntax. Those who will use the LDAPObject and similar=20
mentality will appreciate the latter, and I feel it doesn't confuse=20
things if those methods are documented as object methods.

On Tuesday, November 13, 2001, at 05:01 AM, Michael Str=F6der wrote:

> Jacek Konieczny wrote:
>>
>> On Tue, Nov 13, 2001 at 10:13:54PM +1000, David Leonard wrote:
>>> On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:
>>>
>>>> The two interfaces can coexist.
>>>
>>> um, i'd like to avoid too many ways of doing the same thing.. it=20
>>> leads to
>>> confusion... so, just one way or the other thanks :)
>>
>> In this case IMHO set_option() seems more reasonable.
>
> Go for it.
>
>> But it will break
>> backward compatibility (for those options which are already =
implemented
>> as attributes).
>
> Backward compability to python-ldap with OpenLDAP 1 libs regarding
> options was broken with OpenLDAP 2 patches anyway. I don't mind.
>
>> I won't touch __setattr__() and set_option() of LDAPObject until we
>> decide on some solution.
>
> Go for set_option() since the C module part should map OpenLDAP 2
> API more or less directly.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Documenting python-ldap

[Jacek K. <ja...@bn...>]

Hi,

Good software needs documentation. Especially any kind of API.
I made some basic docstrings for functions I had implemented, but they
are not perfect. And there is no docs for them in Doc/libldap.tex.
I don't thing my english is good enough to do the documentation, but
maybe there is someone here who would like to do this...
The other problem is, that OpenLDAP API has hardly any documentation :-(

Greets,
        Jacek

`errobjects' undeclared

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

David's last check-in of LDAPObject.c

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Modules/LDAPObject.c.diff?r1=1.15&r2=1.16

broke the build:

Modules/LDAPObject.c: In function `l_ldap_result':
Modules/LDAPObject.c:1243: `errobjects' undeclared (first use in
this function)

I don't know how to fix it.

Ciao, Michael.

Re: Python parts of module ldap

[Konstantin C. <Kon...@da...>]

Michael StrЖder wrote:

> As already announced I'd like to contribute some of my LDAP-related
> Python modules to python-ldap.
>
> But I don't want to pollute the module name space with a lot of
> separate names. Therefore I'd suggest that we turn the module ldap
> into a directory-based module package adding more sub-modules later.
>
> ldap/__init__.py would import all symbols from _ldap for the sake of
> backward compability (like ldap.py already does today).
>

Good idea!

Thank you Michael and all who brought python-ldap development back to life
recently! Unfortunately I do not have time to spend on it nowadays.

Regards,
    Konstantin.

--
         * *       Konstantin Chuguev           Francis House
      *      *     Application Engineer         112 Hills Road
    *              Tel: +44 1223 302992         Cambridge CB2 1PQ
D  A  N  T  E      WWW: http://www.dante.net    United Kingdom

Removed files: Makefile.python-1.4

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

David Leonard wrote:
> 
> Removed files:
>         Misc           : Makefile.python-1.4

This also raises the question if the Build/ and Win32/ directories
are still needed.

Any good or bad experiences with building C modules under Win32 with
the help of DistUtils?

Ciao, Michael.

Re: Python parts of module ldap

[Jacek K. <ja...@bn...>]

On Tue, Nov 13, 2001 at 02:34:59PM +0100, Michael Str=F6der wrote:
> Comments?
Sounds like a good idea.

Greets,
        Jacek

Re: Python parts of module ldap

[Federico Di G. <fo...@de...>]

On Tue, 2001-11-13 at 14:34, Michael Str=F6der wrote:
> HI!
>=20
> As already announced I'd like to contribute some of my LDAP-related
> Python modules to python-ldap.
>=20
> But I don't want to pollute the module name space with a lot of
> separate names. Therefore I'd suggest that we turn the module ldap
> into a directory-based module package adding more sub-modules later.
>=20
> ldap/__init__.py would import all symbols from _ldap for the sake of
> backward compability (like ldap.py already does today).
>=20
> Comments?

perfect. my work and other projects (psycopg notably) suck-up all my
time. just relegate my code under a dir, i'll update it when i'll have
some more time.

ciao,
federico (currently fighting with apache auth_ldap)

--=20
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
INIT.D Developer                                           fo...@in...
                             Best friends are often failed lovers. -- Me

Re: Python parts of module ldap

[Rich S. <rs...@zo...>]

+1

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

Python parts of module ldap

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

HI!

As already announced I'd like to contribute some of my LDAP-related
Python modules to python-ldap.

But I don't want to pollute the module name space with a lot of
separate names. Therefore I'd suggest that we turn the module ldap
into a directory-based module package adding more sub-modules later.

ldap/__init__.py would import all symbols from _ldap for the sake of
backward compability (like ldap.py already does today).

Comments?

Ciao, Michael.

Re: ldap.set_option() ready

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

Jacek Konieczny wrote:
> 
> On Tue, Nov 13, 2001 at 10:13:54PM +1000, David Leonard wrote:
> > On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:
> >
> > > The two interfaces can coexist.
> >
> > um, i'd like to avoid too many ways of doing the same thing.. it leads to
> > confusion... so, just one way or the other thanks :)
> 
> In this case IMHO set_option() seems more reasonable.

Go for it.

> But it will break
> backward compatibility (for those options which are already implemented
> as attributes).

Backward compability to python-ldap with OpenLDAP 1 libs regarding
options was broken with OpenLDAP 2 patches anyway. I don't mind.

> I won't touch __setattr__() and set_option() of LDAPObject until we
> decide on some solution.

Go for set_option() since the C module part should map OpenLDAP 2
API more or less directly.

Ciao, Michael.

Re: ldap.set_option() ready

[Jacek K. <ja...@bn...>]

On Tue, Nov 13, 2001 at 10:13:54PM +1000, David Leonard wrote:
> On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:
> 
> > The two interfaces can coexist.
> 
> um, i'd like to avoid too many ways of doing the same thing.. it leads to
> confusion... so, just one way or the other thanks :)

In this case IMHO set_option() seems more reasonable. But it will break
backward compatibility (for those options which are already implemented
as attributes).
Using attributes of LDAPObject for connection-specific options and
set_object() function for global/default options will make mess like
this:


import ldap
ldap.set_option(ldap.OPT_SIZELIMIT,100)   # sets default size limit
l=ldap.initialize("ldap://localhost/")
l.sizelimit=100                           # sets size limit for connection l

As you see the same option is set in two totally different ways. I the 
C API both are set using the same function with only difference is that,
in the first case first argument (LDAP object) is NULL.

I won't touch __setattr__() and set_option() of LDAPObject until we
decide on some solution.
 
I personally still think that the two (attribute, set_option()) solution
can coexist, provided they share as much code as possible.

Greets,
        Jacek

Re: ldap.set_option() ready

[David L. <dav...@it...>]

On Tue, 13 Nov 2001, Jacek Konieczny typed thusly:

> The two interfaces can coexist.

um, i'd like to avoid too many ways of doing the same thing.. it leads to
confusion... so, just one way or the other thanks :)

d
-- 
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Re: ldap.set_option() ready

[Jacek K. <ja...@bn...>]

On Tue, Nov 13, 2001 at 12:25:57AM +0100, Michael Str=F6der wrote:
> Jacek Konieczny wrote:
> >=20
> > I will also make ldap.get_option() function and get_option/set_option
> > methods of LDAPObject.
>=20
> Shouldn't the LDAPObject-related options be implemented by
> __getattr__() and __setattr__()? I have no personal preference but
> this is how it's done today (e.g. "version" etc.) and it's very
> Pythonic.

LDAP API includes ldap_set_option() function. Anybody who knows this API
will search for something similar in python-ldap. The same function is
used to set some global/default options and to set connection-specific
options. It would be quite strange to treat them differently.
I agree, that __getattr__() and __setattr__() are more Pythonic, so I
think it should stay for at least some options. The two interfaces can
coexist. In fact __setattr__() will call set_option() internally, after
translating attribute name to LDAP_OPT_* constant.

Greets,
        Jacek

Re: ldap.set_option() ready

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

David Leonard wrote:
> 
> On Tue, 13 Nov 2001, Michael Ströder typed thusly:
> 
> > Jacek Konieczny wrote:
> > >
> > > I will also make ldap.get_option() function and get_option/set_option
> > > methods of LDAPObject.
> >
> > Shouldn't the LDAPObject-related options be implemented by
> > __getattr__() and __setattr__()? I have no personal preference but
> > this is how it's done today (e.g. "version" etc.) and it's very
> > Pythonic.
> 
> you mean, like this?
> 
>         print ldap.option.api_info
> 
>         ldap.option.debug_level = 2
> 
> i think it is just as easy doing it the current get_option() way,
> and means that OpenLDAP's documentation/manuals remains sensible for
> people who want to read up on what the options mean.
> 
> The only real plus I can think of with attributes is that you have the
> advantage of hasattr() and as you say, it is more pythonic.

As I said, I have no personal preference. We can keep get_option()
to be more compliant with OpenLDAP's LDAP-EXT API. I can do the
Pythonic way in a Python wrapper module above if needed some time.

Ciao, Michael.

Re: result() timeout

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

David Leonard wrote:
> 
> currently when l.result(msgid, all, timeout) is called with a nonzero timeout
> and timeout expires, then None is returned rather than the usual
>  (res_type, value) tuple.
> 
> this change makes result() raise an ldap.TIMEOUT exception instead.
> supposedly this makes it easier to write code to handle result timeouts?

I'm fine with either way. But ldap.TIMEOUT should only be raised if
the timeout value was really nonzero. If the timeout value is zero
returning solely None is the most reasonable way.

I have to look into ldapthreading if I have to change something.

Ciao, Michael.

Re: ldap.set_option() ready

[David L. <dav...@it...>]

On Tue, 13 Nov 2001, Michael Str=F6der typed thusly:

> Jacek Konieczny wrote:
> >
> > I will also make ldap.get_option() function and get_option/set_option
> > methods of LDAPObject.
>
> Shouldn't the LDAPObject-related options be implemented by
> __getattr__() and __setattr__()? I have no personal preference but
> this is how it's done today (e.g. "version" etc.) and it's very
> Pythonic.

you mean, like this?

=09print ldap.option.api_info

=09ldap.option.debug_level =3D 2

i think it is just as easy doing it the current get_option() way,
and means that OpenLDAP's documentation/manuals remains sensible for
people who want to read up on what the options mean.

The only real plus I can think of with attributes is that you have the
advantage of hasattr() and as you say, it is more pythonic.

d
--=20
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8

result() timeout

[David L. <dav...@it...>]

i am cleaning out some of the diffs in my local tree; and want to know if this
change needs to be committed or something different.

currently when l.result(msgid, all, timeout) is called with a nonzero timeout
and timeout expires, then None is returned rather than the usual
 (res_type, value) tuple.

this change makes result() raise an ldap.TIMEOUT exception instead.
supposedly this makes it easier to write code to handle result timeouts?

old way:
	res = l.result(ldap.RES_ANY, 1, timeout)
	if res is None:
		#-- handle timeout
	else:
		typ,msg = res
		#-- handle message

new way:
	try:
		typ,msg = l.result(ldap.RES_ANY, 1, tiemout)
		#-- handle message
	except ldap.TIMEOUT:
		#-- handle timeout

so... ditch or commit?

The current documentation is totally wrong anyway; it says
	"\tIf a timeout occurs, the tuple (None, None) is returned.";
which is false. In any event it should be fixed.


Index: Modules/LDAPObject.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v
retrieving revision 1.14
diff -u -u -r1.14 LDAPObject.c
--- Modules/LDAPObject.c	2001/11/12 14:47:51	1.14
+++ Modules/LDAPObject.c	2001/11/13 02:06:41
@@ -1237,8 +1237,7 @@

     if (res_type == 0) {
 	/* Timeout has occured */
-	Py_INCREF(Py_None);
-    	return Py_None;
+	return PyErr_SetObject(errobjects[LDAP_TIMEOUT], Py_None);
     }

     if (res_type == LDAP_RES_SEARCH_ENTRY
@@ -1321,7 +1320,7 @@
 "\tindefinitely if timeout is negative.  A timeout of 0 will effect\n"
 "\ta poll.  The timeout can be expressed as a floating-point value.\n"
 "\n"
-"\tIf a timeout occurs, the tuple (None, None) is returned.";
+"\tIf a timeout occurs, a TIMEOUT exception is raised.";

 /* ldap_search */

Index: Doc/libldap.tex
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Doc/libldap.tex,v
retrieving revision 1.4
diff -u -u -r1.4 libldap.tex
--- Doc/libldap.tex	2001/11/13 01:50:51	1.4
+++ Doc/libldap.tex	2001/11/13 02:06:43
@@ -525,8 +525,7 @@
 the method will wait indefinitely for a response.
 The timeout can be expressed as a floating-point value, and
 a value of \constant{0} effects a poll.
-If a timeout does occur, the tuple \constant{(None,None)} is returned.
-(This should really have been a \exception{TIMEOUT} exception!)
+If a timeout does occur, a \exception{TIMEOUT} exception is raised.

 The \method{result()} method returns a tuple of the form
 \code{(\textit{result-type}, \textit{result-data})}.

-- 
David Leonard                           Dav...@it...
Dept of Inf. Tech. and Elec. Engg   _   Ph:+61 404 844 850
The University of Queensland       |+|  http://www.itee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Re: ldap.set_option() ready

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

Jacek Konieczny wrote:
> 
> I will also make ldap.get_option() function and get_option/set_option
> methods of LDAPObject.

Shouldn't the LDAPObject-related options be implemented by
__getattr__() and __setattr__()? I have no personal preference but
this is how it's done today (e.g. "version" etc.) and it's very
Pythonic.

Ciao, Michael.

ldap.set_option() ready

[Jacek K. <ja...@bn...>]

Hi,

I have just commited ldap.set_option() function and ldap.OPT_* constants.
It is not perfect yet (probably boolean options don't work as they
should), but it can already be used for TLS certificate validation
setup.

You can try this:

ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
ldap.set_option(ldap.OPT_X_TLS,ldap.OPT_X_TLS_HARD)
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,"cacerts.pem")
ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,1)
l=ldap.initialize("ldaps://some.ldap.host")
l.simple_bind_s("","")

I will also make ldap.get_option() function and get_option/set_option
methods of LDAPObject.

Greets,
        Jacek