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

Is there any possible way to tell what exception has been raised in
python-ldap without catching every single possibile type of
_ldap.LDAPError?

It would be really nice in example included in the python-ldap
documentation if an exception was caught in the following general way:

try:
  <connect, bind and search, as is currently shown>
except:
  <display type of exception and its description>

at the moment, there is no example code with exceptions in the
documentation or distribution and i can't figure out how to catch one
from the exception references provided without trying to catch every
single possibility.

thanks alot, nick.

Hello,

OK, never mind, I eventually figured it out :) Turns out the patches are
hidden inside the RPM's !

I had to do some manual work since I wanted it to work with Python 2.1, but
now I'm not getting any errors ...

I'm looking forward to trying it out :)

Thanks for the contribution!

Jean-François Doyon
Carbon IT
http://methane.org
Tel.: (819) 827-9997
Fax : (819) 827-6653

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of
jf...@se...
Sent: October 22, 2001 5:01 PM
To: Michael Ströder
Cc: pyt...@li...
Subject: Re: Undefined Symbol?

Michael,

I did see it, unfortunately, I'm not sure WHERE to find these patches,
they don't seem to be in the CVS tree! Also, the README in the CVS says it
was tested again OpenLDAP 2.0 and Python 2.0 ... Which is pretty damn
close to what I'm using (Python 2.1.1 with OpenLDAP 2.0.17, although the
files say 2.0.11 for some reason).

Maybe I'll try the RPM's :) I just like hacking things myself!

Thanks!
J.F.



On Mon, 22 Oct 2001, Michael [iso-8859-1] Ströder wrote:

> jf...@se... wrote:
> >
> >
> > I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,
>
> See item 3 on http://python-ldap.sourceforge.net/faq.shtml
>
> Note that applying patches to python-ldap is experimental.
>
> Ciao, Michael.
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>



_______________________________________________
Python-LDAP-dev mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Michael,

I did see it, unfortunately, I'm not sure WHERE to find these patches,
they don't seem to be in the CVS tree! Also, the README in the CVS says it
was tested again OpenLDAP 2.0 and Python 2.0 ... Which is pretty damn
close to what I'm using (Python 2.1.1 with OpenLDAP 2.0.17, although the
files say 2.0.11 for some reason).

Maybe I'll try the RPM's :) I just like hacking things myself!

Thanks!
J.F.



On Mon, 22 Oct 2001, Michael [iso-8859-1] Str=F6der wrote:

> jf...@se... wrote:
> >=20
> >=20
> > I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,
>=20
> See item 3 on http://python-ldap.sourceforge.net/faq.shtml
>=20
> Note that applying patches to python-ldap is experimental.
>=20
> Ciao, Michael.
>=20
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20

jf...@se... wrote:
> 
> 
> I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap,

See item 3 on http://python-ldap.sourceforge.net/faq.shtml

Note that applying patches to python-ldap is experimental.

Ciao, Michael.

Hello,

I just installed OpenLDAP 2.0.17 and the CVS version of python-ldap, and
am having the following error when trying to use it with Zope's
LDAPAdpater:

2001-10-22T17:49:27 ERROR(200) Zope Could not import Products.LDAPAdapter
Traceback (innermost last):
  File /usr/local/Zope-2.4.2/lib/python/OFS/Application.py, line 563, in
import_product
  File /usr/local/Zope-2.4.2/lib/python/Products/LDAPAdapter/__init__.py,
line 90, in ?
  File
/usr/local/Zope-2.4.2/lib/python/Products/LDAPAdapter/LDAPAdapter.py, line
120, in ?
  File /usr/lib/python2.1/site-packages/ldap.py, line 2, in ?
ImportError: /usr/lib/python2.1/site-packages/_ldap.so: undefined symbol:
ldap_ufn_setfilter

I know that that function exists in OpenLDAP, or at least is documented
...

The site mentionned patches, where do I get those, if that's the problem?

Thanks!

J.F.

Michael Str=F6der <mi...@st...> writes:

> Michael Str=F6der wrote:
> >=20
> > Steffen Ries wrote:
> > >
> > > attached is a small (experimental) patch, which enables
> > > 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I
> > > tested it only against 2.0.11 on Redhat 6.2).
> >=20
> > Also doing a
> > >>> del l
> > crashs the interpreter no matter if unbind_s() was called before or
> > not.
>=20
> Steffen, I wonder which Python version you're using. It seems to run
> stable under Python 2.0 but crashes under Python 2.1.x very often.
> Most times in the case when the LDAP connection object is
> deleted/cleaned up. Maybe there were significant changes in
> reference counting, garbage collection etc. introduced in Python
> 2.1?

I'm using both Python 2.0 (Solaris 8) and Python 2.1 (Linux [Redhat
7.1]). I have not seen stability problems and could not reproduce the
problems you had.

I have currently very little time, but I'll try to work on python-ldap
in the near future.

Can you give me more details what you do to crash the interpreter? A
simple bind+search works for me:

--8<--
Python 2.1.1 (#1, Jul 20 2001, 19:59:19)=20
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import ldap
>>> s =3D ldap.open('localhost')
>>> s.version =3D ldap.VERSION3
>>> s.simple_bind_s(...)
>>> s.search_s(...)=20=20
...
>>> del s
>>>=20
--8<--

> Steffen, Konstantin, would you mind glancing over
> http://www.amk.ca/python/2.1/ ?

will do.

/steffen
--=20
ste...@sy...	<> Gravity is a myth -- the Earth sucks!

Michael Ströder wrote:
> 
> Steffen Ries wrote:
> >
> > attached is a small (experimental) patch, which enables
> > 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I
> > tested it only against 2.0.11 on Redhat 6.2).
> 
> Also doing a
> >>> del l
> crashs the interpreter no matter if unbind_s() was called before or
> not.

Steffen, I wonder which Python version you're using. It seems to run
stable under Python 2.0 but crashes under Python 2.1.x very often.
Most times in the case when the LDAP connection object is
deleted/cleaned up. Maybe there were significant changes in
reference counting, garbage collection etc. introduced in Python
2.1?

Steffen, Konstantin, would you mind glancing over
http://www.amk.ca/python/2.1/ ?

Ciao, Michael.

Michael Str=F6der wrote:

>
>As I wrote above setting the "options" attribute fails. Check out
>LDAPSession.__setattr__().
>
I believe this is the section of ldapsession.py to which you refer.
  def set_option(self,name,value):
    """Set LDAPObject option or attribute"""
    if self.openldap2 or name=3D=3D'deref':
      setattr(self.l,name,value)

Based upon the error log, this is definitely the source of (or at least=20
one of the sources of) my problems.
Where is the "openldap2" referred to above.

Apropos of the above I note that web2lapp/cnf.py has the following line
from web2ldapcnf import ldap_def

I have no such definition in webldapcnf. Do I need to add one and, if=20
so, what is the appropriate ref:
openldap2, deref, etc.

>
>
>Sorry, just removing code in web2ldap's modules isn't the solution.
>The solution is to inform the maintainer of your python-ldap RPM or
>patched source tree that attribute "version" and probably some
>others are not exposed properly.
>
I am that maintainer you speak of.

>
>Ciao, Michael.
>


--=20
The information contained in this message is privileged and confi-
dential. If you have received this message in error, please notify=20
the sender at the address or the telephone number set forth below.

Arthur E. Vossberg III
1100 Buckingham Way
Yardley, PA 19067
Telephone: +1 215 295 8207

For secure transmissions over the Internet,=20
please use the sender's gpg public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (SunOS)
Comment: Issued by ar...@rt...

mQGiBDurtG8RBACLL+gvAe9pkG4a45rxCAbPW+Zn+Oy0wdWy/6dQFZ91bbQsf0KM
XFm0EN/9IEqEl2H7xafjUtw4MDNVeYrKM6ikujq9zRIEP3JLCUpxX7DAQ7uK0Yq4
2+WhciR2XxQsMnUnZfd5WcNuC3MmgP6BM1h7mUjhImrxzP+jgYn3Phu+wwCgl5da
e8+JWgAJwM1Pkgi387U7s8sD/2eLgzaTLpCfJ9yFDLT6ItbtYz28LszfNCkSJRYR
pgaXaKnravHvts66PlB3Y96UAh8HMTeLHtytWS0m6UCMIDXAS9QR3JaEk2ig9Oxx
uAXgnSypCGYb5gk29AuDNNOzZfvEeGN2aUPT/TbUom7BkuraxF5WGwX3DuaSlNEE
hpAuA/4+sndzENT1uJ50A1kL2/L6Tf2u7dGgSQyKiEEeegCUWEgNS3bdmWoKzfCi
Sg2ZHFtm0k1xZTCG2lLeuZAzYv5elzk4/4op8dXJcV8qh2eClDwhDaYomLeNdWod
u3QiSDgycx+VPB+Xg35XHRw81ceNvRiAJJFPM1EX50OoiDuQprQsQXJ0IFZvc3Ni
ZXJnIChncGdVc2VyKSA8YXJ0QHJ0di5BV09MYXJ0LmNvbT6IXQQTEQIAHQUCO6u0
bwUJBaOagAULBwoDBAMVAwIDFgIBAheAAAoJELq8qjjqxHt4xEEAn3hp9PXriwv5
mAiDXgi95sq4spg/AJ46P7IMM0NkXs4yV7+47l2UFoeysrkBDQQ7q7UzEAQAuIJc
v9Zjl1qB7+lfZoaqk7FpCRO9MddH2BRkvRvCgfZUDwx8cCYtPE6HcElB06rHGVcn
y8bPbNvrZAHB058/xX46PNTH3XGkUWpwyC6y1XGbGGaNS6QaGWRGJGqFCagMg8Qf
wu6qeyYrc5pldiS0wQOnDz+Ck9gme/UzlJh1yb8AAwcD/jos272U+F5WGvwZ15jo
ic/6wF3LAZBzGEw6oyacY/qR0sesGO9PPDBvvD+93n4OB9FKjwFTeaE8IifO1nXe
TTDPqDy+eGKKCIBROtAU6SqBCzUvwfKWTs2De0z7Orru1fdruZnDW3VhKFeCD+f4
iXWSp1zGa0ZoRkjgobXNE4VziEwEGBECAAwFAjurtTMFCQWjmoAACgkQuryqOOrE
e3ilmgCcDqtqLyPmb0OOWaWP5O6FRxiZVJYAn2xHATJorP9M+TLxtrOaZV0v8NWG
=3DHpkW
-----END PGP PUBLIC KEY BLOCK-----

Konstantin Chuguev wrote:
> 
> Michael Ströder wrote:
> 
> > Michael Ströder wrote:
> > >
> > BTW: I think python-ldap should expose the following constants:
> >
> > LDAP_API_VERSION
> > LDAP_VENDOR_NAME
> > LDAP_VENDOR_VERSION
> >
> 
> It's not quite clear, because python-ldap is itself an API :-)

Obviously you're right. ;-)

> Maybe LDAP_C_API_VERSION or simpler: LDAP_C_API_NAME.
> Currently supported versions are OPENLDAP_1 and OPENLDAP_2...

But I'd really like to have a more fine-grained versioning. How
about:

C_API_VENDOR_NAME
C_API_VENDOR_VERSION

Since the OpenLDAP 2 API seems to be the only one coming with such
constants we have no problems following their naming and versioning
scheme and setting values to reasonable defaults in case of OpenLDAP
1.

Ciao, Michael.

Michael StrЖder wrote:

> Michael StrЖder wrote:
> >
> BTW: I think python-ldap should expose the following constants:
>
> LDAP_API_VERSION
> LDAP_VENDOR_NAME
> LDAP_VENDOR_VERSION
>

It's not quite clear, because python-ldap is itself an API :-)
Maybe LDAP_C_API_VERSION or simpler: LDAP_C_API_NAME.
Currently supported versions are OPENLDAP_1 and OPENLDAP_2...


--
         * *       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

Michael Ströder wrote:
> 
> Art Vossberg wrote:
> > [..]
> > Traceback (most recent call last):
> > [..]
> > NameError: cannot set that field
> > [..]
> > Obviously, most of this data is environmental data, but the last several
> > lines indicate a setoption or __setattr__ problem.
> 
> FYI: With web2ldap I already try to handle differences of
> python-ldap built against different versions of the OpenLDAP libs.

BTW: I think python-ldap should expose the following constants:

LDAP_API_VERSION
LDAP_VENDOR_NAME
LDAP_VENDOR_VERSION

This would make it possible that an application can check more
precise the API vendor and version.

Other constants might be interesting as well:

LDAP_API_FEATURE_*

Ciao, Michael.

Steffen Ries wrote:
> 
> attached is a small (experimental) patch, which enables
> 'start_tls_s()' in python-ldap. The patch requires OpenLDAP 2.0.x (I
> tested it only against 2.0.11 on Redhat 6.2).
> [..]
> A simple demonstration looks like this:
> >>> server = ldap.open('localhost')
> >>> server.version = ldap.VERSION3
> >>> server.start_tls_s()
> >>> server.simple_bind_s(...)
> 
> If the ldap server supports startTLS and the Certificate maps to the
> host, the call to start_tls_s() succeeds, otherwise an exception is
> thrown.

How's the trusted CA cert chain configured? It does not really make
sense to use TLS if the LDAP client does not verify the server's
certificate against a trusted root CA cert.

Also doing a
>>> del l
crashs the interpreter no matter if unbind_s() was called before or
not.

Ciao, Michael.

Art Vossberg wrote:
> 
> >FYI: With web2ldap I already try to handle differences of
> >python-ldap built against different versions of the OpenLDAP libs.
> >This works fairly well with the patches exposing the "version"
> >attribute. I take the presence of the "version" attribute as
> >indicator that the OpenLDAP 2 libs are used.
> >
> What patches are you referring to ?

You can find them in the mailing list archives. Konstantin announced
to check in his patches soon but did not find the time yet, I guess.
The OpenLDAP 2 libs adaption in web2ldap is exactly something I've
implemented for him because he definitely needs LDAPv3 binds
(instead of LDAPv2).

> >However if the python-ldap was built against OpenLDAP 2 libs with
> >patches which does not expose the "version" attribute it is assumed
> >that the OpenLDAP 1 libs are in place and setting the LDAP
> >connection options via attribute "options" obviously fails.
> >
> I looked at ldapsession and grepped everything in site to see where
> openldap version is set.
> However, I am still getting the same error messages.

As I wrote above setting the "options" attribute fails. Check out
LDAPSession.__setattr__().

Sorry, just removing code in web2ldap's modules isn't the solution.
The solution is to inform the maintainer of your python-ldap RPM or
patched source tree that attribute "version" and probably some
others are not exposed properly.

Ciao, Michael.

HI!

I've checked in some modifications to the ldif module.

See details on:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldif.py?rev=1.6&content-type=text/vnd.viewcvs-markup

Please test. Especially those of you still using Python 1.5.x or
prior versions.

Ciao, Michael.

>
>
>FYI: With web2ldap I already try to handle differences of
>python-ldap built against different versions of the OpenLDAP libs.
>This works fairly well with the patches exposing the "version"
>attribute. I take the presence of the "version" attribute as
>indicator that the OpenLDAP 2 libs are used.
>
What patches are you referring to ?

>
>However if the python-ldap was built against OpenLDAP 2 libs with
>patches which does not expose the "version" attribute it is assumed
>that the OpenLDAP 1 libs are in place and setting the LDAP
>connection options via attribute "options" obviously fails.
>
>For those of you interested in the gory details check out module
>ldapsession.py shipped with web2ldap.
>
>
I looked at ldapsession and grepped everything in site to see where 
openldap version is set.
However, I am still getting the same error messages.

I am using web2ldap-20011015 and the most recent python-ldap CVS build.


-- 
The information contained in this message is privileged and confi-
dential. If you have received this message in error, please notify 
the sender at the address or the telephone number set forth below.

Arthur E. Vossberg III
1100 Buckingham Way
Yardley, PA 19067
Telephone: +1 215 295 8207

For secure transmissions over the Internet, 
please use the sender's gpg public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (SunOS)
Comment: Issued by ar...@rt...

mQGiBDurtG8RBACLL+gvAe9pkG4a45rxCAbPW+Zn+Oy0wdWy/6dQFZ91bbQsf0KM
XFm0EN/9IEqEl2H7xafjUtw4MDNVeYrKM6ikujq9zRIEP3JLCUpxX7DAQ7uK0Yq4
2+WhciR2XxQsMnUnZfd5WcNuC3MmgP6BM1h7mUjhImrxzP+jgYn3Phu+wwCgl5da
e8+JWgAJwM1Pkgi387U7s8sD/2eLgzaTLpCfJ9yFDLT6ItbtYz28LszfNCkSJRYR
pgaXaKnravHvts66PlB3Y96UAh8HMTeLHtytWS0m6UCMIDXAS9QR3JaEk2ig9Oxx
uAXgnSypCGYb5gk29AuDNNOzZfvEeGN2aUPT/TbUom7BkuraxF5WGwX3DuaSlNEE
hpAuA/4+sndzENT1uJ50A1kL2/L6Tf2u7dGgSQyKiEEeegCUWEgNS3bdmWoKzfCi
Sg2ZHFtm0k1xZTCG2lLeuZAzYv5elzk4/4op8dXJcV8qh2eClDwhDaYomLeNdWod
u3QiSDgycx+VPB+Xg35XHRw81ceNvRiAJJFPM1EX50OoiDuQprQsQXJ0IFZvc3Ni
ZXJnIChncGdVc2VyKSA8YXJ0QHJ0di5BV09MYXJ0LmNvbT6IXQQTEQIAHQUCO6u0
bwUJBaOagAULBwoDBAMVAwIDFgIBAheAAAoJELq8qjjqxHt4xEEAn3hp9PXriwv5
mAiDXgi95sq4spg/AJ46P7IMM0NkXs4yV7+47l2UFoeysrkBDQQ7q7UzEAQAuIJc
v9Zjl1qB7+lfZoaqk7FpCRO9MddH2BRkvRvCgfZUDwx8cCYtPE6HcElB06rHGVcn
y8bPbNvrZAHB058/xX46PNTH3XGkUWpwyC6y1XGbGGaNS6QaGWRGJGqFCagMg8Qf
wu6qeyYrc5pldiS0wQOnDz+Ck9gme/UzlJh1yb8AAwcD/jos272U+F5WGvwZ15jo
ic/6wF3LAZBzGEw6oyacY/qR0sesGO9PPDBvvD+93n4OB9FKjwFTeaE8IifO1nXe
TTDPqDy+eGKKCIBROtAU6SqBCzUvwfKWTs2De0z7Orru1fdruZnDW3VhKFeCD+f4
iXWSp1zGa0ZoRkjgobXNE4VziEwEGBECAAwFAjurtTMFCQWjmoAACgkQuryqOOrE
e3ilmgCcDqtqLyPmb0OOWaWP5O6FRxiZVJYAn2xHATJorP9M+TLxtrOaZV0v8NWG
=HpkW
-----END PGP PUBLIC KEY BLOCK-----

js...@ne... wrote:
> 
> I have something like uid=someone,ou=ç?«,dc=domain,dc=org. The
> ou value is in gb2312 encoding.

It seems that your DNs are not compliant to RFC2253. All attribute
values should be UTF-8 encoded ISO-10646 Unicode. Check the
component which builds this DN.

Ciao, Michael.

Art Vossberg wrote:
> [..]
> Traceback (most recent call last):
> [..]
> NameError: cannot set that field
> [..]
> Obviously, most of this data is environmental data, but the last several
> lines indicate a setoption or __setattr__ problem.

FYI: With web2ldap I already try to handle differences of
python-ldap built against different versions of the OpenLDAP libs.
This works fairly well with the patches exposing the "version"
attribute. I take the presence of the "version" attribute as
indicator that the OpenLDAP 2 libs are used.

However if the python-ldap was built against OpenLDAP 2 libs with
patches which does not expose the "version" attribute it is assumed
that the OpenLDAP 1 libs are in place and setting the LDAP
connection options via attribute "options" obviously fails.

For those of you interested in the gory details check out module
ldapsession.py shipped with web2ldap.

Ciao, Michael.

I have something like uid=someone,ou=火,dc=domain,dc=org. The ou value is in gb2312 encoding.  If I use PyString_(En/De) the whole dn string, OpenLDAP doesn't like it.  So I have to parse out the ou=, and only PyString_(En/De) that piece, which make things quite bit more complicated, and I did not spend time to figure out why. I choose a quick and easy(dirty ?) way out for myself, and get this thread started. I will certainly vote for someone who can device an effecient and clean way to do it cross platforms. 

Michael Ströder <mi...@st...> wrote:

>js...@ne... wrote:
>> 
>> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in
>> any recent LINUX system
>
>web2ldap based on python-ldap aims to run on Win32 platform too...
>
>Anyway all character set translation should be based on Unicode
>support introduced in Python 1.6 because the codec concept looks
>very clean. There are Unicode codecs for Python based on iconv lib
>if the built-in Python codecs are not sufficient.
>
>> I did try to use PyString_(De/En)code, but it is not very well
>> suited to openldap type of applications, especially if dn has mixed
>> ascii and utf8 encodings.
>
>I'm not sure what you mean with "mixed ascii and utf8 encodings".
>
>UTF-8 is a variable length encoding of the ISO-10646 character set


>which maps the page containing the ASCII characters directly to
>ASCII.
>
>Example with my last name:
>
>>>> unicode('Str?der','iso-8859-1').encode('utf-8')
>'Str\xc3\xb6der'
>
>Ciao, Michael.
>


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Following the advice on the list to delete the references to 'ufn' in 
modules/LDAPObject.c I have been able to get the module to compile and 
it imports without criticism.  However, web2ldap (which is the only 
program presently using pytjon-ldap) no longer works.
 When a user tries to connect, the following error message is generated 
in the apache log:

[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: 
------------------------------------------------------------
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: Unhandled error at 
2001-10-17T04:28:39Z
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: LDAPSession 
instance: <LDAPSession: host:u'rtv.AWOLart.com:389',dn:u''>
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: DOCUMENT_ROOT: 
"/usr/local/apache_1.3.20/htdocs"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: EMBPERL_DEBUG: "2285"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: GATEWAY_INTERFACE: 
"CGI/1.1"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: HTTP_ACCEPT: 
"text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, 
image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, 
*/*;q=0.1"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: 
HTTP_ACCEPT_CHARSET: "ISO-8859-1, utf-8;q=0.66, *;q=0.66"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: 
HTTP_ACCEPT_ENCODING: "gzip, deflate, compress;q=0.9"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: 
HTTP_ACCEPT_LANGUAGE: "en-us"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: HTTP_CONNECTION: 
"keep-alive"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: HTTP_HOST: 
"rtv.awolart.com"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: HTTP_KEEP_ALIVE: "300"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: HTTP_REFERER: 
"http://rtv.awolart.com/web2ldap-fcgi/web2ldap.py"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: HTTP_USER_AGENT: 
"Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4) Gecko/20010915"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: PATH: 
"/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/sbin:/etc"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: PATH_INFO: 
"/searchform"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: PATH_TRANSLATED: 
"/usr/local/apache_1.3.20/htdocs/searchform"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: QUERY_STRING: 
"host=rtv.AWOLart.com%3A389"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: REMOTE_ADDR: 
"207.103.199.116"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: REMOTE_PORT: "36896"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: REQUEST_METHOD: "GET"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: REQUEST_URI: 
"/web2ldap-fcgi/web2ldap.py/searchform?host=rtv.AWOLart.com%3A389"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SCRIPT_FILENAME: 
"/usr/local/web2ldap/fcgi/web2ldap.py"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SCRIPT_NAME: 
"/web2ldap-fcgi/web2ldap.py"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_ADDR: 
"207.103.199.116"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_ADMIN: 
"ar...@rt..."
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_NAME: 
"rtv.AWOLart.com"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_PORT: "80"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_PROTOCOL: 
"HTTP/1.1"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_SIGNATURE: 
"<ADDRESS>Apache/1.3.20 Server at <A 
HREF="mailto:ar...@rt...">rtv.AWOLart.com</A> Port 80</ADDRESS>
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: "
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: SERVER_SOFTWARE: 
"Apache/1.3.20 (Unix) mod_fastcgi/2.2.10 PHP/4.0.6 AuthMySQL/2.20 
mod_perl/1.26 mod_ssl/2.8.4 OpenSSL/0.9.6b"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: TZ: "US/Eastern"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: UNIQUE_ID: 
"O80I989nx3QAADyCOaA"
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: Traceback (most 
recent call last):
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr:   File 
"./pylib/w2lapp/handler.py", line 351, in HandleHTTPRequest
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr:   File 
"/usr/local/web2ldap/pylib/ldapsession.py", line 425, in set_option
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr:     
setattr(self._l,name,value)
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr:   File 
"/usr/local/lib/python2.2/site-packages/ldapthreadlock.py", line 60, in 
__setattr__
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr:     
setattr(self._l,name,value)
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
server "/usr/local/web2ldap/fcgi/web2ldap.py" stderr: NameError: cannot 
set that field
[Wed Oct 17 00:28:39 2001] [error] [client 207.103.199.116] FastCGI: 
incomplete headers (0 bytes) received from server 
"/usr/local/web2ldap/fcgi/web2ldap.py"

Obviously, most of this data is environmental data, but the last several 
lines indicate a setoption or __setattr__ problem.

I am using web2ldap-0.9.6 with Python-2.2 and Openldap-2.0.15. For the 
record, this problem also occurs when I use Python-2.0 and Python-2.1.1.

Any help is appreciated.

-- 
The information contained in this message is privileged and confi-
dential. If you have received this message in error, please notify 
the sender at the address or the telephone number set forth below.

Arthur E. Vossberg III
1100 Buckingham Way
Yardley, PA 19067
Telephone: +1 215 295 8207

For secure transmissions over the Internet, 
please use the sender's gpg public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (SunOS)
Comment: Issued by ar...@rt...

mQGiBDurtG8RBACLL+gvAe9pkG4a45rxCAbPW+Zn+Oy0wdWy/6dQFZ91bbQsf0KM
XFm0EN/9IEqEl2H7xafjUtw4MDNVeYrKM6ikujq9zRIEP3JLCUpxX7DAQ7uK0Yq4
2+WhciR2XxQsMnUnZfd5WcNuC3MmgP6BM1h7mUjhImrxzP+jgYn3Phu+wwCgl5da
e8+JWgAJwM1Pkgi387U7s8sD/2eLgzaTLpCfJ9yFDLT6ItbtYz28LszfNCkSJRYR
pgaXaKnravHvts66PlB3Y96UAh8HMTeLHtytWS0m6UCMIDXAS9QR3JaEk2ig9Oxx
uAXgnSypCGYb5gk29AuDNNOzZfvEeGN2aUPT/TbUom7BkuraxF5WGwX3DuaSlNEE
hpAuA/4+sndzENT1uJ50A1kL2/L6Tf2u7dGgSQyKiEEeegCUWEgNS3bdmWoKzfCi
Sg2ZHFtm0k1xZTCG2lLeuZAzYv5elzk4/4op8dXJcV8qh2eClDwhDaYomLeNdWod
u3QiSDgycx+VPB+Xg35XHRw81ceNvRiAJJFPM1EX50OoiDuQprQsQXJ0IFZvc3Ni
ZXJnIChncGdVc2VyKSA8YXJ0QHJ0di5BV09MYXJ0LmNvbT6IXQQTEQIAHQUCO6u0
bwUJBaOagAULBwoDBAMVAwIDFgIBAheAAAoJELq8qjjqxHt4xEEAn3hp9PXriwv5
mAiDXgi95sq4spg/AJ46P7IMM0NkXs4yV7+47l2UFoeysrkBDQQ7q7UzEAQAuIJc
v9Zjl1qB7+lfZoaqk7FpCRO9MddH2BRkvRvCgfZUDwx8cCYtPE6HcElB06rHGVcn
y8bPbNvrZAHB058/xX46PNTH3XGkUWpwyC6y1XGbGGaNS6QaGWRGJGqFCagMg8Qf
wu6qeyYrc5pldiS0wQOnDz+Ck9gme/UzlJh1yb8AAwcD/jos272U+F5WGvwZ15jo
ic/6wF3LAZBzGEw6oyacY/qR0sesGO9PPDBvvD+93n4OB9FKjwFTeaE8IifO1nXe
TTDPqDy+eGKKCIBROtAU6SqBCzUvwfKWTs2De0z7Orru1fdruZnDW3VhKFeCD+f4
iXWSp1zGa0ZoRkjgobXNE4VziEwEGBECAAwFAjurtTMFCQWjmoAACgkQuryqOOrE
e3ilmgCcDqtqLyPmb0OOWaWP5O6FRxiZVJYAn2xHATJorP9M+TLxtrOaZV0v8NWG
=HpkW
-----END PGP PUBLIC KEY BLOCK-----

js...@ne... wrote:
> 
> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in
> any recent LINUX system

web2ldap based on python-ldap aims to run on Win32 platform too...

Anyway all character set translation should be based on Unicode
support introduced in Python 1.6 because the codec concept looks
very clean. There are Unicode codecs for Python based on iconv lib
if the built-in Python codecs are not sufficient.

> I did try to use PyString_(De/En)code, but it is not very well
> suited to openldap type of applications, especially if dn has mixed
> ascii and utf8 encodings.

I'm not sure what you mean with "mixed ascii and utf8 encodings".

UTF-8 is a variable length encoding of the ISO-10646 character set
which maps the page containing the ASCII characters directly to
ASCII.

Example with my last name:

>>> unicode('Ströder','iso-8859-1').encode('utf-8')
'Str\xc3\xb6der'

Ciao, Michael.

Joe Little wrote:
> 
> I'm merely stating the the python-ldap module needs to maintain its
> ability to be os agnostic.

Yes. Although my personal preference is using Linux as OS it's an
important requirement that python-ldap should run on any platform
where Python has been ported to. If somebody needs special codecs
not part of the Python distribution he/she should look into the
iconv-based Python codec project.

Ciao, Michael.

well, mac is now UNIX, its also already I18N natively

Don't start a flame war without fuel :)....

I'm merely stating the the python-ldap module needs to maintain its 
ability to be os agnostic.

On Tuesday, October 16, 2001, at 10:18 PM, js...@ne... wrote:

> UNIX(LINUX)  is the only OS I know that has the internationalization 
> (i18n) concept. Windows, VMS and many other less known OS, such as 
> milkyway etc., only have the concept of localization (L10?).  This 
> patch may be used for localization purpose as well, but its main target 
> is the i18n type of applications.  Don't know about mac, but since it 
> is mainly a personal system, my guess is that it is just like windows, 
> L10 only.
>
> any way, I appreciate the good work in the free software community, and 
> like to contribute something back.  I have no interest getting into the 
> OS squabbling, especially with mac fans.
>
> Thanks
> J.
>
>
> jml...@ma... wrote:
>
>> I wouldn't suggest that the audience here is 100% linux. Rather, a
>> majority likely is not
>>
>> On Tuesday, October 16, 2001, at 10:41 AM, js...@ne... wrote:
>>
>>> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in 
>>> any
>>> recent LINUX system if the C developement environment is configured. 
>>> If
>>> older than glic 2.2.2, you might have to install the iconvlib
>>> seperately.
>>>
>>> I did try to use PyString_(De/En)code, but it is not very well suited
>>> to openldap type of applications, especially if dn has mixed ascii and
>>> utf8 encodings.  But I will be happy if someone can prove I am wrong.
>>>
>>> Thanks.
>>> J.
>>>
>>>
>>> David Leonard <dav...@it...> wrote:
>>>
>>>>
>>>> On Sat, 13 Oct 2001, js...@ne... typed thusly:
>>>>> I just worked out the python-ldap so that it will convert the
>>>>> local charactors to utf8 or vice versa according to the user locale
>>>>> setup.   This is done because OpenLdap currently only support utf8,
>>>>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>>>>> (simplified Chinese), and it worked.  By no means it is a complete
>>>>> test, but it is a good start, and it worked for me.  The patch was
>>>>> generated against the CVS tree check out yesterday, so it is pretty
>>>>> recent.
>>>>> Here is the patch in the attachment.
>>>>
>>>> hi
>>>>
>>>> sorry i have been unable to respond to you - i had marked your
>>>> message important but have been busy of late. :(
>>>>
>>>> i'm glad you send it to the list, because it will stand a better 
>>>> chance
>>>> of being reviewed there.. a better chance than just sitting in my
>>>> mailbox.
>>>>
>>>> here are my comments from a quick perusal of the diff
>>>>
>>>> ... the diff is reversed. (took me a moment to figure out what was
>>>> going on there!.. the order is 'diff <old> <new>')
>>>>
>>>> ... you're relying on an iconv.h header file, which isn't on every
>>>> system. (especially mine)
>>>>
>>>> .. I think instead to use PyString_Decode() and PyString_Encode()..
>>>> that way you get python unicode string objects.
>>>>
>>>> i'm not an expert on these things, but here is a cut and paste from
>>>> a python header file:
>>>>
>>>> /* Create a string object by decoding the encoded string s of the
>>>>   given size. */
>>>>
>>>> extern DL_IMPORT(PyObject*) PyString_Decode(
>>>>    const char *s,              /* encoded string */
>>>>    int size,                   /* size of buffer */
>>>>    const char *encoding,       /* encoding */
>>>>    const char *errors          /* error handling */
>>>>    );
>>>>
>>>> /* Encodes a char buffer of the given size and returns a
>>>>   Python string object. */
>>>>
>>>> extern DL_IMPORT(PyObject*) PyString_Encode(
>>>>    const char *s,              /* string char buffer */
>>>>    int size,                   /* number of chars to encode */
>>>>    const char *encoding,       /* encoding */
>>>>    const char *errors          /* error handling */
>>>>    );
>>>>
>>>>
>>>> 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
>>>>
>>>> Make sure that you have enough free memory in your temp directory.
>>>>    - Sun StarOffice README
>>>>
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________
>>> Your favorite stores, helpful shopping tools and great gift ideas.
>>> Experience the convenience of buying online with Shop@Netscape!
>>> http://shopnow.netscape.com/
>>>
>>> Get your own FREE, personal Netscape Mail account today at
>>> http://webmail.netscape.com/
>>>
>>>
>>> _______________________________________________
>>> Python-LDAP-dev mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>>>
>>
>>
>
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. 
> Experience the convenience of buying online with Shop@Netscape! 
> http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at 
> http://webmail.netscape.com/
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

to get this thread back on track, does anyone have objections to Michael's
solution?

i.e. leave the data as 'raw' strings, and use codecs.utf_8_decode() when you
know that it is UTF-8 encoded.

d

On Wed, 17 Oct 2001, js...@ne... typed thusly:

> UNIX(LINUX)  is the only OS I know that has the internationalization (i18n) concept. Windows, VMS and many other less known OS, such as milkyway etc., only have the concept of localization (L10?).  This patch may be used for localization purpose as well, but its main target is the i18n type of applications.  Don't know about mac, but since it is mainly a personal system, my guess is that it is just like windows, L10 only.

-- 
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

Make sure that you have enough free memory in your temp directory.
	- Sun StarOffice README

UNIX(LINUX)  is the only OS I know that has the internationalization (i18n) concept. Windows, VMS and many other less known OS, such as milkyway etc., only have the concept of localization (L10?).  This patch may be used for localization purpose as well, but its main target is the i18n type of applications.  Don't know about mac, but since it is mainly a personal system, my guess is that it is just like windows, L10 only.

any way, I appreciate the good work in the free software community, and like to contribute something back.  I have no interest getting into the OS squabbling, especially with mac fans.

Thanks
J.
 

jml...@ma... wrote:

>I wouldn't suggest that the audience here is 100% linux. Rather, a 
>majority likely is not
>
>On Tuesday, October 16, 2001, at 10:41 AM, js...@ne... wrote:
>
>> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in any 
>> recent LINUX system if the C developement environment is configured. If 
>> older than glic 2.2.2, you might have to install the iconvlib 
>> seperately.
>>
>> I did try to use PyString_(De/En)code, but it is not very well suited 
>> to openldap type of applications, especially if dn has mixed ascii and 
>> utf8 encodings.  But I will be happy if someone can prove I am wrong.
>>
>> Thanks.
>> J.
>>
>>
>> David Leonard <dav...@it...> wrote:
>>
>>>
>>> On Sat, 13 Oct 2001, js...@ne... typed thusly:
>>>> I just worked out the python-ldap so that it will convert the
>>>> local charactors to utf8 or vice versa according to the user locale
>>>> setup.   This is done because OpenLdap currently only support utf8,
>>>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>>>> (simplified Chinese), and it worked.  By no means it is a complete
>>>> test, but it is a good start, and it worked for me.  The patch was
>>>> generated against the CVS tree check out yesterday, so it is pretty
>>>> recent.
>>>> Here is the patch in the attachment.
>>>
>>> hi
>>>
>>> sorry i have been unable to respond to you - i had marked your
>>> message important but have been busy of late. :(
>>>
>>> i'm glad you send it to the list, because it will stand a better chance
>>> of being reviewed there.. a better chance than just sitting in my 
>>> mailbox.
>>>
>>> here are my comments from a quick perusal of the diff
>>>
>>> ... the diff is reversed. (took me a moment to figure out what was
>>> going on there!.. the order is 'diff <old> <new>')
>>>
>>> ... you're relying on an iconv.h header file, which isn't on every
>>> system. (especially mine)
>>>
>>> .. I think instead to use PyString_Decode() and PyString_Encode()..
>>> that way you get python unicode string objects.
>>>
>>> i'm not an expert on these things, but here is a cut and paste from
>>> a python header file:
>>>
>>> /* Create a string object by decoding the encoded string s of the
>>>   given size. */
>>>
>>> extern DL_IMPORT(PyObject*) PyString_Decode(
>>>    const char *s,              /* encoded string */
>>>    int size,                   /* size of buffer */
>>>    const char *encoding,       /* encoding */
>>>    const char *errors          /* error handling */
>>>    );
>>>
>>> /* Encodes a char buffer of the given size and returns a
>>>   Python string object. */
>>>
>>> extern DL_IMPORT(PyObject*) PyString_Encode(
>>>    const char *s,              /* string char buffer */
>>>    int size,                   /* number of chars to encode */
>>>    const char *encoding,       /* encoding */
>>>    const char *errors          /* error handling */
>>>    );
>>>
>>>
>>> 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
>>>
>>> Make sure that you have enough free memory in your temp directory.
>>>    - Sun StarOffice README
>>>
>>>
>>>
>>
>>
>> __________________________________________________________________
>> Your favorite stores, helpful shopping tools and great gift ideas. 
>> Experience the convenience of buying online with Shop@Netscape! 
>> http://shopnow.netscape.com/
>>
>> Get your own FREE, personal Netscape Mail account today at 
>> http://webmail.netscape.com/
>>
>>
>> _______________________________________________
>> Python-LDAP-dev mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>>
>
>


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

I wouldn't suggest that the audience here is 100% linux. Rather, a 
majority likely is not

On Tuesday, October 16, 2001, at 10:41 AM, js...@ne... wrote:

> The iconv is part of glibc 2.2.2 and above, so iconv.h should be in any 
> recent LINUX system if the C developement environment is configured. If 
> older than glic 2.2.2, you might have to install the iconvlib 
> seperately.
>
> I did try to use PyString_(De/En)code, but it is not very well suited 
> to openldap type of applications, especially if dn has mixed ascii and 
> utf8 encodings.  But I will be happy if someone can prove I am wrong.
>
> Thanks.
> J.
>
>
> David Leonard <dav...@it...> wrote:
>
>>
>> On Sat, 13 Oct 2001, js...@ne... typed thusly:
>>> I just worked out the python-ldap so that it will convert the
>>> local charactors to utf8 or vice versa according to the user locale
>>> setup.   This is done because OpenLdap currently only support utf8,
>>> so  one has to make the  translation.   I tested on zh_CN.GB2312
>>> (simplified Chinese), and it worked.  By no means it is a complete
>>> test, but it is a good start, and it worked for me.  The patch was
>>> generated against the CVS tree check out yesterday, so it is pretty
>>> recent.
>>> Here is the patch in the attachment.
>>
>> hi
>>
>> sorry i have been unable to respond to you - i had marked your
>> message important but have been busy of late. :(
>>
>> i'm glad you send it to the list, because it will stand a better chance
>> of being reviewed there.. a better chance than just sitting in my 
>> mailbox.
>>
>> here are my comments from a quick perusal of the diff
>>
>> ... the diff is reversed. (took me a moment to figure out what was
>> going on there!.. the order is 'diff <old> <new>')
>>
>> ... you're relying on an iconv.h header file, which isn't on every
>> system. (especially mine)
>>
>> .. I think instead to use PyString_Decode() and PyString_Encode()..
>> that way you get python unicode string objects.
>>
>> i'm not an expert on these things, but here is a cut and paste from
>> a python header file:
>>
>> /* Create a string object by decoding the encoded string s of the
>>   given size. */
>>
>> extern DL_IMPORT(PyObject*) PyString_Decode(
>>    const char *s,              /* encoded string */
>>    int size,                   /* size of buffer */
>>    const char *encoding,       /* encoding */
>>    const char *errors          /* error handling */
>>    );
>>
>> /* Encodes a char buffer of the given size and returns a
>>   Python string object. */
>>
>> extern DL_IMPORT(PyObject*) PyString_Encode(
>>    const char *s,              /* string char buffer */
>>    int size,                   /* number of chars to encode */
>>    const char *encoding,       /* encoding */
>>    const char *errors          /* error handling */
>>    );
>>
>>
>> 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
>>
>> Make sure that you have enough free memory in your temp directory.
>>    - Sun StarOffice README
>>
>>
>>
>
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. 
> Experience the convenience of buying online with Shop@Netscape! 
> http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at 
> http://webmail.netscape.com/
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>