python-ldap-dev Mailing List for python-ldap (Page 41)

On 3/1/07, "Michael Str=F6der" <mi...@st...> wrote:
> On 5:55:55 pm 2007-02-28 "Hiroki Sakagami" <sak...@gm...> wrote:
> >
> > Thank you for your reply.  So, I can get the socket object by adding
> > such a method manually. Is there any chance there will be support for
> > LDAP_OPT_DESC in future python-ldap?
>
> Feel free to submit a patch.

OK, I'm going to try to implement it.

--
Hiroki Sakagami

Hiroki Sakagami wrote:
> 
> Thank you for your reply.  So, I can get the socket object by adding
> such a method manually. Is there any chance there will be support for
> LDAP_OPT_DESC in future python-ldap?

Not sure what you mean with "socket object". Let's read
http://www.openldap.org/lists/openldap-software/200102/msg00290.html
once again:

"You can use ldap_get_option(ld, LDAP_OPT_DESC, &sd) to access
the primary file descriptor associated with a session handle."

This function of the OpenLDAP C SDK returns just the OS' file
descriptor. I never worked with asyncore. Not sure what you need.

Ciao, Michael.

On 5:55:55 pm 2007-02-28 "Hiroki Sakagami" <sak...@gm...> wrote:
>
> Thank you for your reply.  So, I can get the socket object by adding
> such a method manually. Is there any chance there will be support for
> LDAP_OPT_DESC in future python-ldap?

Feel free to submit a patch.

Ciao, Michael.

Hi,

Thank you for your reply.  So, I can get the socket object by adding
such a method manually. Is there any chance there will be support for
LDAP_OPT_DESC in future python-ldap?

--
Hiroki Sakagami

On 2/27/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > On 2/20/07, Hiroki Sakagami <sak...@gm...> wrote:
> >> Hi,
> >>
> >> I'm trying to use python-ldap with asyncore event loop.  Since
> >> asyncore's event source is a socket object, I can't use search() and
> >> result() style polling.  Is it possible to access a socket object in
> >> the LDAPObject instance?
> >
> > http://www.openldap.org/lists/openldap-software/200102/msg00290.html
> >
> > hope this help
>
> One would have to patch Modules/options.c and Modules/constants.c for
> this to theoretically work.
>
> Ciao, Michael.
>

Anil Jangity wrote:
> I notice this in other areas of my code as well.
> 
> Here is a trace of a modify:
> 
> *** ldap://host:389 - SimpleLDAPObject.modify_ext (('cn=Shilpa J,
> uid=anilj, ou=People, o=entic.net', [(0, 'mail',
> [u'shi...@so...'])], None, None),{})
> Error - <type 'exceptions.TypeError'>: ('expected a string in the
> list', u'shi...@so...')
> 
> 
> The problem is, it seems work on and off. When the modifications or
> searches are done without the unicode string,  it works. But later
> when I try to do the same thing again for some reason it trys to do
> the LDAP operation using unicode lists: [u'abc']
> 
> Thats when it fails.

You have to pass solely raw strings to python-ldap since the API does
not handle Unicode strings automatically.

 u'shi...@so...'.encode('utf-8')

Ciao, Michael.

I notice this in other areas of my code as well.

Here is a trace of a modify:

*** ldap://host:389 - SimpleLDAPObject.modify_ext (('cn=3DShilpa J,
uid=3Danilj, ou=3DPeople, o=3Dentic.net', [(0, 'mail',
[u'shi...@so...'])], None, None),{})
Error - <type 'exceptions.TypeError'>: ('expected a string in the
list', u'shi...@so...')


The problem is, it seems work on and off. When the modifications or
searches are done without the unicode string,  it works. But later
when I try to do the same thing again for some reason it trys to do
the LDAP operation using unicode lists: [u'abc']

Thats when it fails.

Is it something else in my code that is causing it or is something
else wrong in the python-ldap?

I'll see if I can find more details/code. I was just wondering if you
guys knew off the top of your heads...





On 2/25/07, Michael Str=F6der <mi...@st...> wrote:
> Anil Jangity wrote:
> >
> > url =3D ''.join((self.server, base, '?', attr, '?', scope, '?', filter,=
 '?'))
> > try:
> >     print url
> >     ldap_url =3D ldapurl.LDAPUrl(url)
>
> BTW: See also 2nd example on
>
> http://python-ldap.sourceforge.net/doc/python-ldap/ldapurl-example.html
>
> Ciao, Michael.
>

Alain Spineux wrote:
> On 2/20/07, Hiroki Sakagami <sak...@gm...> wrote:
>> Hi,
>>
>> I'm trying to use python-ldap with asyncore event loop.  Since
>> asyncore's event source is a socket object, I can't use search() and
>> result() style polling.  Is it possible to access a socket object in
>> the LDAPObject instance?
>
> http://www.openldap.org/lists/openldap-software/200102/msg00290.html
>
> hope this help

One would have to patch Modules/options.c and Modules/constants.c for
this to theoretically work.

Ciao, Michael.

Anil Jangity wrote:
> 
> url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?'))
> try:
>     print url
>     ldap_url = ldapurl.LDAPUrl(url)

BTW: See also 2nd example on

http://python-ldap.sourceforge.net/doc/python-ldap/ldapurl-example.html

Ciao, Michael.

Anil Jangity wrote:
> (thanks for all the help in my previous posts)
> 
> Hi,
> 
> I am seeing a peculiar problem in this area of the code. I don't know
> exactly how to reproduce it. It almost like I have to wait a while and
> I see this problem.
> 
> url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?'))
> try:
>     print url
>     ldap_url = ldapurl.LDAPUrl(url)
>     print ldap_url.attrs
>     print attr
> except ValueError:
>     print "Bad URL"
> 
> The output is:
> 
> ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mai...@en...?
> [u'uid']
> uid
> Error - <type 'exceptions.TypeError'>: ('expected string in list', u'uid')

I can't reproduce the error since you didn't provide enough code.

But this simply works regarding module ldapurl:

>>> u=u'ldap://somehost.com:389/ou=People,
o=entic.net?uid?one?mai...@en...?'
>>> ldap_url=ldapurl.LDAPUrl(u)
>>> ldap_url.attrs
[u'uid']

Ciao, Michael.

(thanks for all the help in my previous posts)

Hi,

I am seeing a peculiar problem in this area of the code. I don't know
exactly how to reproduce it. It almost like I have to wait a while and
I see this problem.

url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?'))
try:
    print url
    ldap_url = ldapurl.LDAPUrl(url)
    print ldap_url.attrs
    print attr
except ValueError:
    print "Bad URL"

The output is:

ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mai...@en...?
[u'uid']
uid
Error - <type 'exceptions.TypeError'>: ('expected string in list', u'uid')


I am not sure if this is with my Pylons (web development framework) or
something specific to python-ldap.

Let me know if you can give me pointers on how I can try to troubleshoot this.

Thanks,
Anil

http://www.openldap.org/lists/openldap-software/200102/msg00290.html

hope this help

On 2/20/07, Hiroki Sakagami <sak...@gm...> wrote:
> Hi,
>
> I'm trying to use python-ldap with asyncore event loop.  Since
> asyncore's event source is a socket object, I can't use search() and
> result() style polling.  Is it possible to access a socket object in
> the LDAPObject instance?
>
> Regards,
>
> --
> Hiroki Sakagami
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>


-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you

Hi,

I'm trying to use python-ldap with asyncore event loop.  Since
asyncore's event source is a socket object, I can't use search() and
result() style polling.  Is it possible to access a socket object in
the LDAPObject instance?

Regards,

--
Hiroki Sakagami

On Mon, 19 Feb 2007 12:04:46 +0100
Michael Ströder <mi...@st...> wrote:

> jph...@fr... wrote:
> > 
> > I can not use 8 bits chars in search or add functions while I
> > have no issue with these characters in Luma :-( It seems to be related to string
> > encoding. Luma makes an intensive use of the "unicode" function. So I tried that
> > piece of code but without success:
> > 
> >>>> import ldap
> >>>> CON=ldap.open('localhost.localdomain')
> >>>> CON.simple_bind_s('','')
> >>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th�*)')
> 
> You have to pass raw strings to python-ldap since the API does not
> handle Unicode strings automatically.
> 
> So something like u'(cn=th�*)'.encode('utf-8').
> 
> Not sure what the � is in your e-mail though. Therefore I'd recommend
> not to directly write 8-bit chars into the Python source code. Rather
> use the escaping \x..
> 
> Complete example with my last name within Python shell and shell charset
> being UTF-8.
> 
> Python 2.5 (r25:51908, Nov 27 2006, 19:14:46)
> [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ustr=unicode('Ströder','utf-8')
> >>> ustr
> u'Str\xf6der'
> >>> ustr.encode('utf-8')
> 'Str\xc3\xb6der'
> >>>
> 
> Ciao, Michael.
> 
Thanks to you (and Bjorn ;-)). It works far better now. Life would have been far easier if English was full of strange chars :-)

Jean-Philippe

jph...@fr... wrote:
> 
> I can not use 8 bits chars in search or add functions while I
> have no issue with these characters in Luma :-( It seems to be related to string
> encoding. Luma makes an intensive use of the "unicode" function. So I tried that
> piece of code but without success:
> 
>>>> import ldap
>>>> CON=ldap.open('localhost.localdomain')
>>>> CON.simple_bind_s('','')
>>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th�*)')

You have to pass raw strings to python-ldap since the API does not
handle Unicode strings automatically.

So something like u'(cn=th�*)'.encode('utf-8').

Not sure what the � is in your e-mail though. Therefore I'd recommend
not to directly write 8-bit chars into the Python source code. Rather
use the escaping \x..

Complete example with my last name within Python shell and shell charset
being UTF-8.

Python 2.5 (r25:51908, Nov 27 2006, 19:14:46)
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr=unicode('Ströder','utf-8')
>>> ustr
u'Str\xf6der'
>>> ustr.encode('utf-8')
'Str\xc3\xb6der'
>>>

Ciao, Michael.

jph...@fr...:
> Hi,
> 
> I was used to work with phpldapadmin, then discovered luma. Now I need something
> more specific to my needs, and thus interested in python-ldap.
> 
> Starting was really easy :-) Unfortunately, I discovered a bug in my application
> this week-end: I can not use 8 bits chars in search or add functions while I
> have no issue with these characters in Luma :-( It seems to be related to string
> encoding. Luma makes an intensive use of the "unicode" function. So I tried that
> piece of code but without success:
> 
> >>> import ldap
> >>> CON=ldap.open('localhost.localdomain')
> >>> CON.simple_bind_s('','')
> >>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th?)')

<snip>

> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6:
> ordinal not in range(128)

LDAP uses utf8 - so convert any umlauts or whatever to utf8 before doing a query.
Mostly anything can be converted _to_ utf8, but not will convert back to the 
encoding you came from. 

def utf8_encode(str):
    return unicode(str, "iso-8859-1").encode("utf-8")

def utf8_decode(str):
    return unicode(str, "utf-8").encode("iso-8859-1")

Usage:
filter = utf8_encode('cn=Bjørn Ove Grøtan')

Just change from iso-8859-1 to whatever encoding you use by default.

--
Regards
 
Bjørn Ove Grøtan
Luma Debian Maintainer

Hi,

I was used to work with phpldapadmin, then discovered luma. Now I need something
more specific to my needs, and thus interested in python-ldap.

Starting was really easy :-) Unfortunately, I discovered a bug in my application
this week-end: I can not use 8 bits chars in search or add functions while I
have no issue with these characters in Luma :-( It seems to be related to string
encoding. Luma makes an intensive use of the "unicode" function. So I tried that
piece of code but without success:

>>> import ldap
>>> CON=ldap.open('localhost.localdomain')
>>> CON.simple_bind_s('','')
>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th')

exceptions.UnicodeEncodeError                        Traceback (most recent call
last)

/home/jpht/informatique/programmation/python/scripts/under_development/<console>

/usr/lib/python2.3/site-packages/ldap/ldapobject.py in search_s(self, base,
scope, filterstr, attrlist, attrsonly)
    466
    467   def
search_s(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0):
--> 468     return
self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,timeout=self.timeout)
    469
    470   def
search_st(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0,timeout=-1):

/usr/lib/python2.3/site-packages/ldap/ldapobject.py in search_ext_s(self, base,
scope, filterstr, attrlist, attrsonly, serverctrls, clientctrls, timeout,
sizelimit)
    459
    460   def
search_ext_s(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0):
--> 461     msgid =
self._ldap_call(self._l.search_ext,base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
    462     return self.result(msgid,all=1,timeout=timeout)[1]
    463

/usr/lib/python2.3/site-packages/ldap/ldapobject.py in _ldap_call(self, func,
*args, **kwargs)
     92     try:
     93       try:
---> 94         result = func(*args,**kwargs)
     95       finally:
     96         self._ldap_object_lock.release()

UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6:
ordinal not in range(128)

I went quickly through this list, but was not sure of understanding the answer
;-( Could someone help me?

Jean-Philippe

P.S.: I am running slapd 2.2.23 and python-ldap 2.0.4 (debian sarge)

Yes, exactly. While we are at it, can we try to compile in sasl
support? The catch, so far, is, again, heimdal. It is not winsock
aware.

However, I have heard that it can be done. I am just stuck as to how.

Perhaps I should just ask a couple simple questions:

Should we use heimdal or MIT kerberos? I have been assuming heimdal,
as MIT kerberos does not compile with mingw/msys.

Should we use mingw/msys, or vc++? I have been assuming mingw/msys.

Is there a way to get mingw to use MIT kerberos libraries compiled with vc++?

If anyone can point me in the right direction, I would be grateful.

Thanks,
Jonathan Bowman

On 2/10/07, Anil Jangity <an...@en...> wrote:
> There is a windows python-ldap (2.0.6 py 2.4) available here:
> http://www.agescibs.org/mauro/
>
> But its a little old...
>
> Anyone working on getting one up for python 2.5 and latest python-ldap release?
>
> On 2/10/07, Jonathan Bowman <bo...@us...> wrote:
> > I have been trying to build python-ldap on Windows. First, I need to
> > build openldap on Windows using openssl, heimdal (kerberos 5, gssapi,
> > etc.), and cyrus-sasl. I am doing this using mingw (as I assume that
> > is what python-ldap uses).
> >
> > OpenSSL is not a problem, but then I get stuck on heimdal, which keeps
> > me from compiling cyrus-sasl. Should I be using MIT Kerberos instead?
> > (I do not know how to build MIT Kerberos using mingw). I am using
> > MSYS, heimdal has a problem with sockets on Windows.
> >
> > Can anyone give me any hints at all? At this point, I do not know how
> > to do this without getting involved in altering significant source
> > code in heimdal, which is beyond my means.
> >
> > Thanks for any response,
> > Jonathan Bowman
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job easier.
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> >
>

There is a windows python-ldap (2.0.6 py 2.4) available here:
http://www.agescibs.org/mauro/

But its a little old...

Anyone working on getting one up for python 2.5 and latest python-ldap release?

On 2/10/07, Jonathan Bowman <bo...@us...> wrote:
> I have been trying to build python-ldap on Windows. First, I need to
> build openldap on Windows using openssl, heimdal (kerberos 5, gssapi,
> etc.), and cyrus-sasl. I am doing this using mingw (as I assume that
> is what python-ldap uses).
>
> OpenSSL is not a problem, but then I get stuck on heimdal, which keeps
> me from compiling cyrus-sasl. Should I be using MIT Kerberos instead?
> (I do not know how to build MIT Kerberos using mingw). I am using
> MSYS, heimdal has a problem with sockets on Windows.
>
> Can anyone give me any hints at all? At this point, I do not know how
> to do this without getting involved in altering significant source
> code in heimdal, which is beyond my means.
>
> Thanks for any response,
> Jonathan Bowman
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

I have been trying to build python-ldap on Windows. First, I need to
build openldap on Windows using openssl, heimdal (kerberos 5, gssapi,
etc.), and cyrus-sasl. I am doing this using mingw (as I assume that
is what python-ldap uses).

OpenSSL is not a problem, but then I get stuck on heimdal, which keeps
me from compiling cyrus-sasl. Should I be using MIT Kerberos instead?
(I do not know how to build MIT Kerberos using mingw). I am using
MSYS, heimdal has a problem with sockets on Windows.

Can anyone give me any hints at all? At this point, I do not know how
to do this without getting involved in altering significant source
code in heimdal, which is beyond my means.

Thanks for any response,
Jonathan Bowman

Convinced :-)

Best regards.

On 1/29/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> >
> > Python is a language made to help and facilitate the developer work :
> > - the developer dont need to test the result of any function, python
> > (or the library) raise an exception if something is wrong.
> > - the developer dont need to worry about the memory allocation, the
> > garbage collector do it for him.
> > - the developer dont need to close a file, the system do it for him
> > when the object is released
> > - the developer don't need to worry for long living LDAP connection,
> > ReconnectLDAPObject  auto reconnect automatically for him :-)
> > - python-ldap is also thread safe .....
>
> Your list rather arguments for adding SimpleLDAPObject.__del__() if not
> implemented yet (I have to look at it).
>
> > Then why does the developer have to encapsulate any ldap statement into=
 a
> >
> > try:
> > except ldap.SERVER_DOWN,e:
> >    SimpleLDAPObject.unbind_s(self)
>
> Because in case of ldap.SERVER_DOWN the application might have some
> means for fail-over, smart error handling or similar. python-ldap is
> rather low-level. I expect application developers to wrap something
> around SimpleLDAPObject which better suits there needs.
>
> And I'd like to avoid breaking existing code. Calling unbind_s() twice
> raises
> ldap.LDAPError: LDAP connection invalid
>
> Do you have an overview how other database modules handle such cases?
>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Alain Spineux wrote:
> 
> Python is a language made to help and facilitate the developer work :
> - the developer dont need to test the result of any function, python
> (or the library) raise an exception if something is wrong.
> - the developer dont need to worry about the memory allocation, the
> garbage collector do it for him.
> - the developer dont need to close a file, the system do it for him
> when the object is released
> - the developer don't need to worry for long living LDAP connection,
> ReconnectLDAPObject  auto reconnect automatically for him :-)
> - python-ldap is also thread safe .....

Your list rather arguments for adding SimpleLDAPObject.__del__() if not
implemented yet (I have to look at it).

> Then why does the developer have to encapsulate any ldap statement into a
> 
> try:
> except ldap.SERVER_DOWN,e:
>    SimpleLDAPObject.unbind_s(self)

Because in case of ldap.SERVER_DOWN the application might have some
means for fail-over, smart error handling or similar. python-ldap is
rather low-level. I expect application developers to wrap something
around SimpleLDAPObject which better suits there needs.

And I'd like to avoid breaking existing code. Calling unbind_s() twice
raises
ldap.LDAPError: LDAP connection invalid

Do you have an overview how other database modules handle such cases?

Ciao, Michael.

Alain,

thanks for reviewing the code of ldapobject.py thoroughly.

Alain Spineux wrote:
> 
> Finally I found every object contains its own lock ! (if the used ldap
> library is reentrant)
> and their was no bottleneck. I was happy :-)

Yes, if linked against libldap_r (check your setup.cfg).

> But _ldap_function_call is still used to call _ldap.initialize at some place
> 
> [root@fc6-eg ldap]# grep _ldap.initialize *.py
> ldapobject.py:    self._l =
> ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
> ldapobject.py:        self._l =
> ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
> ldapobject.py:      self._l = self._ldap_call(_ldap.initialize,self._uri)
> 
> why not to replace the use of _ldap_function_call by the more
> appropriate _ldap_call, already used in the last line !

Hmm, IMO it's the other way round. I'd rather consider it a stupid
copy&paste bug that self._ldap_call() is invoked for wrapping
_ldap.initialize() within SmartLDAPObject. I've fixed and committed this.

Please review OpenLDAP's ldap.h. You'll find that ldap_initialize() is a
completely different thing.

> And that way
> debugging will provide and uri for initialise call!

ldap.functions._ldap_function_call() also can produce debug output.

But you have to explicitly set module vars ldap._trace_level,
ldap._trace_file and ldap._trace_stack_limit to enable it. The latter
two being optional off course.

Ciao, Michael.

Hello

I was a little afraid by the advertisement I found

Thread-lock:
Basically calls into the LDAP lib are serialized by the module-wide
lock _ldapmodule_lock.

and wanted to know more about this.
Finally I found every object contains its own lock ! (if the used ldap
library is reentrant)
and their was no bottleneck. I was happy :-)

But _ldap_function_call is still used to call _ldap.initialize at some place

[root@fc6-eg ldap]# grep _ldap.initialize *.py
ldapobject.py:    self._l =
ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
ldapobject.py:        self._l =
ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
ldapobject.py:      self._l = self._ldap_call(_ldap.initialize,self._uri)

why not to replace the use of _ldap_function_call by the more
appropriate _ldap_call, already used in the last line ! And that way
debugging will provide and uri for initialise call!

here is the patch

*** ldap.orig/ldapobject.py     Sat Jan 27 01:57:50 2007
--- ldap/ldapobject.py  Sun Jan 28 02:34:56 2007
***************
*** 66,72 ****
      self._trace_stack_limit = trace_stack_limit
      self._uri = uri
      self._ldap_object_lock = self._ldap_lock()
!     self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
      self.timeout = -1
      self.protocol_version = ldap.VERSION3

--- 66,73 ----
      self._trace_stack_limit = trace_stack_limit
      self._uri = uri
      self._ldap_object_lock = self._ldap_lock()
!     self._l = self._ldap_call(_ldap.initialize,self._uri)
!
      self.timeout = -1
      self.protocol_version = ldap.VERSION3

***************
*** 732,738 ****
          ))
        try:
          # Do the connect
!         self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
          self._restore_options()
          # StartTLS extended operation in case this was called before
          if self._start_tls:
--- 733,740 ----
          ))
        try:
          # Do the connect
!         self._l = self._ldap_call(_ldap.initialize,self._uri)
!
          self._restore_options()
          # StartTLS extended operation in case this was called before
          if self._start_tls:





--
Alain Spineux
aspineux gmail com
May the sources be with you

This is a good point of view!
Anyway I try my _LAST_ arguments.

Python is a language made to help and facilitate the developer work :
- the developer dont need to test the result of any function, python
(or the library) raise an exception if something is wrong.
- the developer dont need to worry about the memory allocation, the
garbage collector do it for him.
- the developer dont need to close a file, the system do it for him
when the object is released
- the developer don't need to worry for long living LDAP connection,
ReconnectLDAPObject  auto reconnect automatically for him :-)
- python-ldap is also thread safe .....

Then why does the developer have to encapsulate any ldap statement into a

try:
except ldap.SERVER_DOWN,e:
    SimpleLDAPObject.unbind_s(self)

whereas=09the library can do it for him

Anyway we made a good job !

Tanks for your support.

On 1/27/07, "Michael Str=F6der" <mi...@st...> wrote:
> On 12:59:58 pm 2007-01-27 "Alain Spineux" <asp...@gm...> wrote:
> >
> > And what about the idea to put the
> >
> > try:
> > except ldap.SERVER_DOWN,e:
> >    SimpleLDAPObject.unbind_s(self)
> >
> > in the function _ldap_call too ?
> > This will correct also SimpleLDAPObject ?
>
> There is nothing wrong with SimpleLDAPObject. The application is supposed
> to catch and handle ldap.SERVER_DOWN. Additionally SimpleLDAPObject and
> ReconnectLDAPObject shall behave in the same way. And IMO they do now.
>
> Ciao, Michael.
>
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

On 12:59:58 pm 2007-01-27 "Alain Spineux" <asp...@gm...> wrote:
>
> And what about the idea to put the
>
> try:
> except ldap.SERVER_DOWN,e:
>    SimpleLDAPObject.unbind_s(self)
>
> in the function _ldap_call too ?
> This will correct also SimpleLDAPObject ?

There is nothing wrong with SimpleLDAPObject. The application is supposed
to catch and handle ldap.SERVER_DOWN. Additionally SimpleLDAPObject and
ReconnectLDAPObject shall behave in the same way. And IMO they do now.

Ciao, Michael.