[ python-Bugs-1076790 ] test test_codecs failed

Thu Dec 2 17:23:18 CET 2004

Bugs item #1076790, was opened at 2004年12月01日 15:41
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal &#268;iha&#345; (nijel)
Assigned to: Nobody/Anonymous (nobody)
Summary: test test_codecs failed
Initial Comment:
test test_codecs failed -- Traceback (most recent call
last):
 File
"/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py",
line 446, in test_nameprep
 raise test_support.TestFailed("Test 3.%d: %s" %
(pos+1, str(e)))
TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9'
----------------------------------------------------------------------
>Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月02日 17:23
Message:
Logged In: YES 
user_id=38388
The punycode codec uses the .upper() method on Unicode objects.
Since this method uses Py_UNICODE_TOUPPER(), any difference
in case mapping between the Unicode DB used in Python and the
one used in glibc will be noticable as a result of 
--with-wctype-functions.
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月02日 17:03
Message:
Logged In: YES 
user_id=192186
Compiling without --with-wctype-functions "fixes" this problem.
I still don't see what has wctype functions to do with this.
They are used for operations like is this numeric,
alphanumeric, upper,... I'd like to trace this bug either it
is in Python or glibc, but I still don't know what of glibc
functions do influence this test.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月02日 16:40
Message:
Logged In: YES 
user_id=38388
Do you get the same error when compiling without
--with-wctype-functions ?
If not, then we'll just have to close this report as "won't
fix" - the
reason is that we as Python developers don't have control over
what glibc does or does not do. 
Unfortunately, there's not way to disable the failing tests
since 
the configure option is not available to the Python program.
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月02日 12:07
Message:
Logged In: YES 
user_id=192186
Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so
there must be either bug in it or in Python, I can't tell.
Any idea how to find out?
----------------------------------------------------------------------
Comment By: Pierre (pierre42)
Date: 2004年12月01日 22:30
Message:
Logged In: YES 
user_id=512388
I have the same problem
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月01日 19:37
Message:
Logged In: YES 
user_id=192186
I understand the question, but I have no idea how to find
this information inside glibc.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月01日 19:33
Message:
Logged In: YES 
user_id=38388
The wctype functions must have been built using tables from 
the Unicode code point database. Python's own APIs for this
were built using the Unicode DB 3.2. My question is whether
you know which version the glibc was built from.
It is not surprising that the two tests fail if the underlying 
Unicode DB versions differ.
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月01日 18:29
Message:
Logged In: YES 
user_id=192186
I'm not sure what means "uses", but I found several mentions
of Unicode 3.2 in code and in changelogs.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月01日 18:20
Message:
Logged In: YES 
user_id=38388
Ah, now I understand: it is well possible that the Unicode
database versions differ. Python uses version 3.2.
Do you know which version glibc 2.3.3 uses ?
Note that for portability it is usually better not to use wctype
functions.
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月01日 17:32
Message:
Logged In: YES 
user_id=192186
The problem seems to be in glibc, when I remove
--with-wctype-functions, it passes. Or could it be in Python
interface to wctype functions?
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月01日 17:21
Message:
Logged In: YES 
user_id=192186
gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
Yes, I'm building UCS4 version.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月01日 17:16
Message:
Logged In: YES 
user_id=38388
Sorry: I misread glibc as gcc. Still, this sounds a lot like
a broken compiler.
BTW, are you building a UCS4 version ?
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月01日 17:15
Message:
Logged In: YES 
user_id=38388
The tests pass just fine on my machine. 
Is it possible that your compiler is broken ? 
gcc 2.3.3 is *very* old !
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月01日 16:26
Message:
Logged In: YES 
user_id=192186
System information:
i386
kernel 2.6.8
glibc 2.3.3
----------------------------------------------------------------------
Comment By: Michal &#268;iha&#345; (nijel)
Date: 2004年12月01日 15:59
Message:
Logged In: YES 
user_id=192186
It's clean build root with no other python, so it has no
chance to pickup bad modules.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2004年12月01日 15:53
Message:
Logged In: YES 
user_id=38388
Please make sure that Python is picking up the correct modules.
You can do so, buy running Python in verbose mode (python -vv).
----------------------------------------------------------------------
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470