python-ldap-dev

delete_s() result

[Michael E. <men...@ka...>]

Hi all -
Does a succesful ldap.delete_s() call return an empty list?

It seems to be the case but the documentation doesn't specify what the 
return value should be.

On a related note, if this is the correct return value from that call, 
then searching, modifying and deleting all work properly on a Mac OS X 
build of python-ldap even though there is an error message at the end 
of the setup.py build script.

Cheers
Mike

Re: delete_s() result

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

Michael Engelhart wrote:
 > Does a succesful ldap.delete_s() call return an empty list?

Hmm, according to the ancient __doc__ string it should return None.

But maybe this changed because of the new implementation of delete_s() in 
the Python wrapper class ldap.ldapobject.SimpleLDAPObject.

Best bet is to ignore the result of delete_s(). It won't contain any useful 
information. In opposite delete() returns the msgid as usual for async methods.

Ciao, Michael.

Re: delete_s() result

[Michael E. <men...@ka...>]

Great - thanks.   The result of the operation is succesful either way=20
in that it deletes the dn passed to it which is really all I care about=20=

anyway.  I'll  just ignore results from delete.

Mike
On Tuesday, October 29, 2002, at 10:28  AM, Michael Str=F6der wrote:

> Michael Engelhart wrote:
> > Does a succesful ldap.delete_s() call return an empty list?
>
> Hmm, according to the ancient __doc__ string it should return None.
>
> But maybe this changed because of the new implementation of delete_s()=20=

> in the Python wrapper class ldap.ldapobject.SimpleLDAPObject.
>
> Best bet is to ignore the result of delete_s(). It won't contain any=20=

> useful information. In opposite delete() returns the msgid as usual=20
> for async methods.
>
> Ciao, Michael.
>

Re: delete_s() result

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

Michael Engelhart wrote:
> The result of the operation is succesful either way in 
> that it deletes the dn passed to it which is really all I care about 
> anyway.  I'll  just ignore results from delete.

Thanks to the early design decision of David you don't have to do error 
handling by checking result codes. If an error occurs during deletion of an 
entry an exception of class ldap.LDAPError or a derived error class is raised.

You can safely ignore results of add_s(), bind_s(), delete_s(), modify_s(), 
modrdn_s(), rename_s() and unbind_s().

Ciao, Michael.

Re: delete_s() result

[Michael E. <men...@ka...>]

Very cool.  That's the way it should be!

maybe that little tidbit should be in the documentation somewhere?=20
although now it's archived in the mailing list... :-)

Mike
On Tuesday, October 29, 2002, at 12:07  PM, Michael Str=F6der wrote:

>
> Thanks to the early design decision of David you don't have to do=20
> error handling by checking result codes. If an error occurs during=20
> deletion of an entry an exception of class ldap.LDAPError or a derived=20=

> error class is raised.
>
> You can safely ignore results of add_s(), bind_s(), delete_s(),=20
> modify_s(), modrdn_s(), rename_s() and unbind_s().
>
> Ciao, Michael.

Re: delete_s() result

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

Michael Engelhart wrote:
>> Thanks to the early design decision of David you don't have to do 
>> error handling by checking result codes. If an error occurs during 
>> deletion of an entry an exception of class ldap.LDAPError or a derived 
>> error class is raised.
> 
> maybe that little tidbit should be in the documentation somewhere? 

http://python-ldap.sourceforge.net/doc/python-ldap/node9.html

Ciao, Michael.

Re: delete_s() result

[Michael E. <men...@ka...>]

right - I guess was thinking more along the lines of directly in the=20
documentation on the ldap operations page, having a paragraph that says=20=

"For the following methods, x(), y(), z(), ldap.LDAPError exceptions=20
are raised instead of returning error codes - click <a=20
href=3D"http://python-ldap.sourceforge.net/doc/python-ldap/node9.html=20
">here</a>  for more information on the Exceptions that can occur."

In my case, I read through the exception page and didn't "get" that=20
delete_s doesn't return error codes because  there is documentation=20
like this mixed into the LDAP operations page for say the result()=20
method:
The result() method returns a tuple of the form (result-type,=20
result-data). The first element, result-type is a string, being one of:=20=

'RES_BIND', 'RES_SEARCH_ENTRY', 'RES_SEARCH_RESULT', 'RES_MODIFY',=20
'RES_ADD', 'RES_DELETE', 'RES_MODRDN', or 'RES_COMPARE'. (The module=20
constants RES_* are set to these strings, for your convenience.)

This method does return codes and it seems to me that based on that if=20=

it's not explicitly stated that other methods would as well.    =20
Personally I would like to see the documentation have examples for each=20=

function written in python but I doubt anyone has time for that.  I'll=20=

start collecting mine and maybe put them up somewhere.

Mike

On Tuesday, October 29, 2002, at 12:28  PM, Michael Str=F6der wrote:

> Michael Engelhart wrote:
>>> Thanks to the early design decision of David you don't have to do=20
>>> error handling by checking result codes. If an error occurs during=20=

>>> deletion of an entry an exception of class ldap.LDAPError or a=20
>>> derived error class is raised.
>> maybe that little tidbit should be in the documentation somewhere?
>
> http://python-ldap.sourceforge.net/doc/python-ldap/node9.html
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Re: delete_s() result

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

Michael Engelhart wrote:
> right - I guess was thinking more along the lines of directly in the 
> documentation

Documentation... (sigh!)

There are even sub-modules completely undocumented...

Ciao, Michael.