[ python-Bugs-1470212 ] mailbox.PortableUnixMailbox fails to parse 'From ' in body
Bugs item #1470212, was opened at 2006-04-13 23:35 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Lars Kellogg-Stedman (larsks) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.PortableUnixMailbox fails to parse 'From ' in body Initial Comment: I have a Unix mailbox file that contains the following text in the body of a message: ---[ cut here ]--- EFCO also offers casements with integral blinds. See:=20 http://www.efcocorp.com/public/earm/products/default.asp?j=3D1&P=3D43&L=3D= 1=20 >From that page, select select "Features and Benefits" from under the heading "Product Overview"=20 ---[ cut here ]--- mailbox.PortableUnixMailbox erroneously interprets the "From" at the beginning of the line as the beginning of a new message. Since 'From ' is only a valid header at the beginning of a message, perhaps the module could look at the following line and see if it looks like an RFC2822 header before accepting 'From ' as a message delimiter. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-02 08:28 Message: Logged In: YES user_id=11375 See the comment in mailbox.py in the UnixMailbox class, too. UnixMailbox uses a stricter regex to look for from lines, but this proves too strict in practice so PortableUnixMailbox is much less strict. mbox format isn't very good, and we're just stuck with this behaviour. Closing this bug as "won't fix". -- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 04:30 Message: Logged In: YES user_id=1185570 Use rfc822.py in lieu of mailbox to first parse the message into an rfc822.Message... then pass it to the Mailbox.PortableUnixMailbox constructor. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol
Bugs item #1531662, was opened at 2006-07-31 12:58 Message generated for change (Comment added) made by gdm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed Resolution: None Priority: 7 Submitted By: gideon may (gdm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Build fails on MacOSX with missing symbol Initial Comment: When compiling the latest svn version on MacOS, the build fails with the following error in libpython2.5.a: ld: Undefined symbols: _init_types libtool: internal link edit command failed When I add Modules/_typesmodule.c to Modules/Setup.dist everything is hunky-dory, but am not sure if this is the correct place since python seems to compile ok on Linux without the addition -- >Comment By: gideon may (gdm) Date: 2006-08-02 14:48 Message: Logged In: YES user_id=117359 The error was completely mine, you were right about junk files still laying around. Have been able to create a clean build, both with and without frameworks -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-31 21:58 Message: Logged In: YES user_id=580910 I cannot reproduce this with the current head (svnversion says 51008). Did you do a clean build? Maybe some junk from a previous build caused problems. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-31 21:43 Message: Logged In: YES user_id=580910 Did you build a unix or framework install? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533105 ] NetBSD build with --with-pydebug causes SIGSEGV
Bugs item #1533105, was opened at 2006-08-02 13:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD build with --with-pydebug causes SIGSEGV Initial Comment: The testInfiniteRecursion test in Lib/test/test_exceptions.py causes Python to segfault if it has been compiled on NetBSD with --with-pydebug. This is due to the fact that the default stack size on NetBSD is 2MB and Python tries to allocate memory for debugging information on the stack. The documentation (README under 'Setting the optimization/debugging options'?) should be updated to state that if you want to run the test suite with debugging enabled in the interpreter, you are advised to increase the stack size, probably to 4096. This issue is also in release24-maint. Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 U _GLOBAL_OFFSET_TABLE_ 00 f ffi.c 000332 T ffi_call 00 U ffi_call_SYSV 00 U ffi_closure_SYSV 000456 T ffi_closure_SYSV_inner 00 T ffi_prep_args 000252 T ffi_prep_cif_machdep 000612 T ffi_prep_closure 00 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 00 s 00 s 00 s 00 s 000109 n epilogue 00 T ffi_call_SYSV 000116 T ffi_closure_SYSV 00 U ffi_closure_SYSV_inner 00 U ffi_prep_args 000109 n noretval 71 n retdouble 59 n retfloat 46 n retint 95 n retint64 83 n retlongdouble 000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 s 00 U _GLOBAL_OFFSET_TABLE_ 00 f ffi.c 000332 T ffi_call 00 U ffi_call_SYSV 00 U ffi_closure_SYSV 000456 T ffi_closure_SYSV_inner 00 T ffi_prep_args 000252 T ffi_prep_cif_machdep 000612 T ffi_prep_closure 00 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 00 s 00 s 00 s 00 s 000109 n epilogue 00 T ffi_call_SYSV 000116 T ffi_closure_SYSV 00 U ffi_closure_SYSV_inner 00 U ffi_prep_args 000109 n noretval 71 n retdouble 59 n retfloat 46 n retint 95 n retint64 83 n retlongdouble 000109 n
[ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files
Bugs item #1532483, was opened at 2006-08-01 09:52 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Vincent Povirk (madewokherd) Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. -- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:28 Message: Logged In: YES user_id=44345 Vincent, A simple workaround would be to define a fully quoting dialect: class quoted_excel(csv.excel): quoting=csv.QUOTE_NONNUMERIC # or QUOTE_ALL That would cause your generated CSV files to start with a quote character, e.g.: "ID","FOO" 1,"bar" 2,"bAz" Try that and see if it makes Excel 2003 happy. Skip -- Comment By: Vincent Povirk (madewokherd) Date: 2006-08-01 13:01 Message: Logged In: YES user_id=553355 Thanks for your response. Yes, it's definitely a bug in Excel 2003 (as it also complains about files it saved). I do not have a later version of Excel to test. Microsoft has a page about this issue that seems to say 2003 is the last version with that problem: http://support.microsoft.com/kb/323626/ Their solution is worse than the problem, I'd be interested in seeing how a later version behaves. I know that if the first cell is quoted, Excel will open it without complaining. I think the best solution would be to quote the first cell if it starts with ID by introducing a new QUOTE_ constant. I don't know how that part of the code works (I'm too lazy to read things that aren't written in python); maybe it's more reasonable to quote any field starting with ID. I don't know of any other uses that would break, but I'm not in touch with many csv users. -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533164 ] Installed but not listed *.pyo break bdist_rpm
Bugs item #1533164, was opened at 2006-08-02 18:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Installed but not listed *.pyo break bdist_rpm Initial Comment: This bug is forwarded from redhat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198877 --- Description of problem: setup.py fails to build rpm. How reproducible: Always Steps to Reproduce: 1. Create dir "foo" with these files: foo.py setup.py setup.py contains: #!/usr/bin/env python from distutils.core import setup setup( name='foo', version='0.1', py_modules=['foo'], ) contents of file foo.py is not important. 2. from the 'foo' directory run python setup.py bdist_rpm Actual results: building of rpm fails with Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/foo-0.1-1-buildroot error: Installed (but unpackaged) file(s) found: /usr/lib/python2.4/site-packages/foo.pyo Expected results: The command above should create a rpm package. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533164&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530959 ] distutils doesn't notice --with-pydebug
Bugs item #1530959, was opened at 2006-07-29 13:45 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: distutils doesn't notice --with-pydebug Initial Comment: As it stands (as of r50921), building a C extension module first with a debug build of Python (built with --with-pydebug), then with a regular Python build (without --with-pydebug) does not cause distutils to recompile the extension module as it should. This leads to undefined symbol errors at runtime when the module is loaded. The attached patch against Lib/distutils/command/build.py causes distutils.command.build to append '-pydebug' to the platform-specific directory name (e.g., 'linux-i686-2.5') if Python was compiled with --with-pydebug. -- >Comment By: Collin Winter (collinwinter) Date: 2006-08-02 13:12 Message: Logged In: YES user_id=1344176 I've updated the patch to r51046. Also attached is an entry for Misc/NEWS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS?
Bugs item #1532726, was opened at 2006-08-01 23:20
Message generated for change (Comment added) made by jwnmulder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan-Willem (jwnmulder)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect behaviour of PyUnicode_EncodeMBCS?
Initial Comment:
Using python 2.4.3
This behaviour is not reproducable on a window or
linux machine. I found the bug when trying to find a
problem on python 2.4.3 ported to the xbox.
running the next two commands
test_string = 'encode me'
print repr(test_string.encode('mbcs'))
results on windows in : 'encode me'
and on the xbox : 'encode me\\x00'
The problem is that 'PyUnicode_EncodeMBCS' returns an
PyStringObject that contains the data 'encode me' but
with an object size of 10.
string_repr(test_string) assumes the string contains
a 0 character and encodes it as '\\x00'
looking at the function 'PyUnicode_EncodeMBCS(const
Py_UNICODE *p, int size, const char *errors)' there
are basicly two functions
{
mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size,
NULL, 0, NULL, NULL);
repr = PyString_FromStringAndSize(NULL, mbcssize);
}
WideCharToMultiByte returns the nummer of bytes
needed for the buffer, because of the string
termination this functions returns 10.
PyString_FromStringAndSize assumes its second
argument to be the number of needed characters, not
bytes. So an easy fix would be
to change
repr = PyString_FromStringAndSize(NULL, mbcssize);
in
repr = PyString_FromStringAndSize(NULL, mbcssize -
1);
Just checked the 2.4.3 svn trunk and it contains the
same bug.
--
>Comment By: Jan-Willem (jwnmulder)
Date: 2006-08-02 19:44
Message:
Logged In: YES
user_id=770969
and the result for the xbox
10
101 110 99 111 100 101 32 109 101 0
11
101 110 99 111 100 101 32 109 101 0 0
It seems the xbox calculates an extra character for a '\0'
count(L"encode me", -1);
results on both platforms in ret = 10
So I think this bug can be closed and clasified as an xbox
bug... Not so hard for us to fix, almost all api calls for
dlls are emulated in our application, so it is easy enough
to put a fix in for us.
--
Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-08-02 07:31
Message:
Logged In: YES
user_id=1200846
I think this is not related to that patch.
On my win2000sp4, teminating null character is not passed to
PyUnicode_EncodeMBCS.
//
// patch for debug (release24-maint branch)
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 51033)
+++ Objects/unicodeobject.c (working copy)
@@ -2782,6 +2782,20 @@
char *s;
DWORD mbcssize;
+{ /* debug */
+
+int i;
+
+printf("> %d\n", size);
+
+for (i = 0; i < size; ++i) {
+ printf("%d ", (int)p[i]);
+}
+
+printf("\n");
+
+} /* debug */
+
/* If there are no characters, bail now! */
if (size==0)
return PyString_FromString("");
//
// a.py
test_string = 'encode me'
print repr(test_string.encode('mbcs'))
//
// result
R:\>py a.py
> 9
101 110 99 111 100 101 32 109 101
'encode me'
[7660 refs]
And I tried this.
#include
#include
#include
void count(LPCWSTR w, int size)
{
char *buf; int i;
const int ret = ::WideCharToMultiByte(
CP_ACP,
0,
w,
size,
NULL,
0,
NULL,
NULL
);
if (ret == 0)
{
printf("error\n");
}
else
{
printf("%d\n", ret);
}
buf = (char*)malloc(ret);
::WideCharToMultiByte(
CP_ACP,
0,
w,
size,
buf,
ret,
NULL,
NULL
);
for (i = 0; i < ret; ++i)
{
printf("%d ", (int)buf[i]);
}
printf("\n");
free(buf);
}
int main()
{
count(L"encode me", 9);
count(L"encode me", 10); /* include null charater */
}
/*
9
101 110 99 111 100 101 32 109 101
10
101 110 99 111 100 101 32 109 101 0
*/
As stated in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp
, WideCharToMultiByte never output null character if source
string doesn't contain null character. So I think usage of
WideCharToMultiByte is correct.
I don't know why, but probably some behavior difference
should exist between win2000 and xbox. (ie: xbox calls
PyUnicode_EncodeMBCS with size 10 ... or WideChar
[ python-Bugs-1524938 ] PEP MemoryError with a lot of available memory gc not called
Bugs item #1524938, was opened at 2006-07-18 22:46
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Matusevich (markmat)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP MemoryError with a lot of available memory gc not called
Initial Comment:
Also the gc behavior is consistent with the
documentation, I beleave it is wrong. I think, that Gc
should be called automatically before any memory
allocation is raised.
Example 1:
for i in range(700):
a = [range(500)]
a.append(a)
print i
This example will crash on any any PC with less then
20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at
i==7.
Also, this example can be fixed by addition of a call
to gc.collect() in the loop, in real cases it may be
unreasonable.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-02 17:52
Message:
Logged In: YES
user_id=764593
Doing it everywhere would be a lot of painful changes.
Adding the "oops, failed, call gc and try again" to to
PyMem_* (currently PyMem_Malloc, PyMem_Realloc, PyMem_New,
and PyMem_Resize, but Brett may be changing that) is far
more reasonable.
Whether it is safe to call gc from there is a different
question.
--
Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 16:19
Message:
Logged In: YES
user_id=1337765
Sorry, my last comment was to illume (I am slow typer :( )
--
Comment By: Mark Matusevich (markmat)
Date: 2006-07-23 16:11
Message:
Logged In: YES
user_id=1337765
This is exectly what I meant.
For my recollection, this is the policy in Java GC. I never
had to handle MemoryError in Java, because I knew, that I
really do not have any more memory.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-23 16:00
Message:
Logged In: YES
user_id=21627
This is very difficult to implement. The best way might be
to introduce yet another allocation function, one that
invokes gc before failing, and call that function in all
interesting places (of which there are many).
Contributions are welcome and should probably start with a
PEP first.
--
Comment By: Rene Dudfield (illume)
Date: 2006-07-19 19:20
Message:
Logged In: YES
user_id=2042
Perhaps better than checking before every memory allocation,
would be to check once a memory error happens in an allocation.
That way there is only the gc hit once there is low memory.
So...
res = malloc(...);
if(!res) {
gc.collect();
}
res = malloc(...);
if(!res) {
raise memory error.
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1525343 ] Webserver TypeError: expected read buffer, NoneType found
Bugs item #1525343, was opened at 2006-07-19 10:53
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: jbet (jbeisert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Webserver TypeError: expected read buffer, NoneType found
Initial Comment:
When I'm using the python webserver I got the
following message for every access by my client.
Soryy, I have no experience in Python, so I cannot
help. This is only a report.
HTTPdaemon_v1.0.0 listening on port 8001
Exception happened during processing of request from
('192.168.1.9', 33917)
Traceback (most recent call last):
File "/home/jb/bin/lib/python2.5/SocketServer.py",
line 463, in
process_request_thread
self.finish_request(request, client_address)
File "/home/jb/bin/lib/python2.5/SocketServer.py",
line 254, in
finish_request
self.RequestHandlerClass(request, client_address,
self)
File "/home/jb/bin/lib/python2.5/SocketServer.py",
line 521, in __init__
self.handle()
File
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line
316, in handle
self.handle_one_request()
File
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line
310, in
handle_one_request
method()
File
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py",
line 53, in
do_GET
self.handle_request()
File
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py",
line 56, in
handle_request
httpreq = HSHTTPRequest(self)
File
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py",
line 254, in
__init__
keep_blank_values = True
File "/home/jb/bin/lib/python2.5/cgi.py", line 462,
in __init__
fp = StringIO(qs)
TypeError: expected read buffer, NoneType found
Exception happened during processing of request from
('192.168.1.9', 33918)
Traceback (most recent call last):
File "/home/jb/bin/lib/python2.5/SocketServer.py",
line 463, in
process_request_thread
self.finish_request(request, client_address)
File "/home/jb/bin/lib/python2.5/SocketServer.py",
line 254, in
finish_request
self.RequestHandlerClass(request, client_address,
self)
File "/home/jb/bin/lib/python2.5/SocketServer.py",
line 521, in __init__
self.handle()
File
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line
316, in handle
self.handle_one_request()
File
"/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line
310, in
handle_one_request
method()
File
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py",
line 53, in
do_GET
self.handle_request()
File
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py",
line 56, in
handle_request
httpreq = HSHTTPRequest(self)
File
"./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py",
line 254, in
__init__
keep_blank_values = True
File "/home/jb/bin/lib/python2.5/cgi.py", line 462,
in __init__
fp = StringIO(qs)
TypeError: expected read buffer, NoneType found
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-02 18:04
Message:
Logged In: YES
user_id=764593
I suspect that changing
>>> fp = StringIO(qs)
to
>>> fp = StringIO(qs or "")
would fix the problem.
If so, this is arguably a bug in myghty. qs was already
set to "" unless sys.argv[1] or environ['QUERY_STRING']had
a value. Neither of these should ever be None. (They
should be either a string, or not found.)
--
Comment By: Chad Whitacre (whit537)
Date: 2006-08-01 15:04
Message:
Logged In: YES
user_id=340931
Thanks for the report. Can I ask how you came to use the
as-yet-unreleased Python 2.5 if you have no experience with
Python? It looks like you are having this problem with
Myghty. Does that require Python 2.5?
FWIW, this looks to me like a problem with Myghty's use of
the cgi module, not a problem with Python itself.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533481 ] CTypes _as_parameter_ not working as documented
Bugs item #1533481, was opened at 2006-08-02 16:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: CTypes _as_parameter_ not working as documented Initial Comment: Reference: http://docs.python.org/dev/lib/ctypes-calling-functions- with-own-custom-data-types.html According to this document, I should be able to use my own objects with ctypes, provided I have an _as_parameter_ attribute set on my object. However, this does not work properly when the foreign function's argtypes have been set. This is because the _as_parameter_ access is not done until after the argument types are checked. Attached is a patch that adds _as_parameter_ checking to the types provided by _ctypes.c so that the feature works as documented for both typed and untyped foreign functions. (Patch is against: svn rev 50859) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533481 ] CTypes _as_parameter_ not working as documented
Bugs item #1533481, was opened at 2006-08-02 16:11 Message generated for change (Comment added) made by shane_holloway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: CTypes _as_parameter_ not working as documented Initial Comment: Reference: http://docs.python.org/dev/lib/ctypes-calling-functions- with-own-custom-data-types.html According to this document, I should be able to use my own objects with ctypes, provided I have an _as_parameter_ attribute set on my object. However, this does not work properly when the foreign function's argtypes have been set. This is because the _as_parameter_ access is not done until after the argument types are checked. Attached is a patch that adds _as_parameter_ checking to the types provided by _ctypes.c so that the feature works as documented for both typed and untyped foreign functions. (Patch is against: svn rev 50859) -- >Comment By: Shane Holloway (shane_holloway) Date: 2006-08-02 16:13 Message: Logged In: YES user_id=283742 A related patch is http://python.org/sf/1532975 that simplifies the implementation of _as_parameter_ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531405 ] format_exception raises if str(exception) raises
Bugs item #1531405, was opened at 2006-07-30 17:06 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current [EMAIL PROTECTED] that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533486 ] long -> Py_ssize_t (C/API 1.2.1)
Bugs item #1533486, was opened at 2006-08-02 18:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533486&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: long -> Py_ssize_t (C/API 1.2.1) Initial Comment: In the C/API reference manual section 1.2.1, should "assuming sizeof(long) >= sizeof(char*)" change long to Py_ssize_t? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533486&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533491 ] C/API sec 10 is clipped
Bugs item #1533491, was opened at 2006-08-02 18:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533491&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: C/API sec 10 is clipped Initial Comment: As of 2.5b2, section 10 of the C/API reference manual seems clipped. Sections 10.4, 10.5, and 10.6 are at best placeholders, and 10.8 isn't even that. (It looks like they could be either on their own as sections, or inlined to an earlier section, and both places are TBD, but the section doesn't make this as obvious.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533491&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1533493 ] Tools/modulator does not exist (ext 1.4)
Bugs item #1533493, was opened at 2006-08-02 18:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: Tools/modulator does not exist (ext 1.4) Initial Comment: As of 2.5b2, Extending and Embedding section 1.4 says that modulator is included with the windows installer. It wasn't. The text suggested likely alternate locations of Tools/ modulator/ or Tools/Scripts/Modul*, but these were also missing. (I see Tools/modulator/ in the svn repository; it just wasn't installed on windows.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-960860 ] botched html for index subheadings
Bugs item #960860, was opened at 2004-05-26 10:17 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: botched html for index subheadings Initial Comment: In the index, if a topic has subtopics, it should be listed as """ topic subtopic1 subtopic2 """ In some cases (such as the reference manual entries for module, or object(continued)), it is correct. In other cases (such as the entries for name, or the first column of object), the "..." wrapper is left out, so that the subentries appear to be normal entries that just happen to be out of alphabetical order. -- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:32 Message: Logged In: YES user_id=764593 It was fixed as of 2.5b2 (possibly earlier). Thank you. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 16:15 Message: Logged In: YES user_id=3066 This appears to be fine in the 2.4.3 and development versions of the documentation. If I'm missing something, please be specific about what you think is wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-960860 ] botched html for index subheadings
Bugs item #960860, was opened at 2004-05-26 10:17 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: botched html for index subheadings Initial Comment: In the index, if a topic has subtopics, it should be listed as """ topic subtopic1 subtopic2 """ In some cases (such as the reference manual entries for module, or object(continued)), it is correct. In other cases (such as the entries for name, or the first column of object), the "..." wrapper is left out, so that the subentries appear to be normal entries that just happen to be out of alphabetical order. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:32 Message: Logged In: YES user_id=764593 It was fixed as of 2.5b2 (possibly earlier). Thank you. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 16:15 Message: Logged In: YES user_id=3066 This appears to be fine in the 2.4.3 and development versions of the documentation. If I'm missing something, please be specific about what you think is wrong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531405 ] format_exception raises if str(exception) raises
Bugs item #1531405, was opened at 2006-07-30 17:06 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current [EMAIL PROTECTED] that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. -- >Comment By: Jp Calderone (kuran) Date: 2006-08-02 18:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> -- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193190 ] MACOSX_DEPLOYMENT_TARGET checked incorrectly
Bugs item #1193190, was opened at 2005-04-30 20:15 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Bob Ippolito (etrepum) Summary: MACOSX_DEPLOYMENT_TARGET checked incorrectly Initial Comment: MACOSX_DEPLOYMENT_TARGET should be checked to be >= the configure time value (or not set). Currently, it checks for equality. For example, this is necessary in order to use a Python built for Mac OS X 10.3 but build an extension with features specific to Mac OS X 10.4. Backport candidate to 2.4, patches attached. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-17 10:44 Message: Logged In: YES user_id=580910 Applied as revision 45490 on the trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 14:07
Message generated for change (Comment added) made by etrepum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 9
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
>Comment By: Bob Ippolito (etrepum)
Date: 2006-08-02 22:10
Message:
Logged In: YES
user_id=139309
I've attached a patch which should resolve this issue.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-28 23:21
Message:
Logged In: YES
user_id=33168
I'd like to see a deprecation warning so old code continues
to work. struct is way to loose and needs to be tightened
up, but that might not fully happen until py3k.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 15:44
Message:
Logged In: YES
user_id=849994
I think that's a question for python-dev.
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 15:31
Message:
Logged In: YES
user_id=139309
That wasn't really intentional, but the old behavior looks a bit suspect:
$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'
We could change it to check for floats and do a DeprecationWarning?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 14:51
Message:
Logged In: YES
user_id=849994
Bob?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS?
Bugs item #1532726, was opened at 2006-08-01 14:20
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jan-Willem (jwnmulder)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect behaviour of PyUnicode_EncodeMBCS?
Initial Comment:
Using python 2.4.3
This behaviour is not reproducable on a window or
linux machine. I found the bug when trying to find a
problem on python 2.4.3 ported to the xbox.
running the next two commands
test_string = 'encode me'
print repr(test_string.encode('mbcs'))
results on windows in : 'encode me'
and on the xbox : 'encode me\\x00'
The problem is that 'PyUnicode_EncodeMBCS' returns an
PyStringObject that contains the data 'encode me' but
with an object size of 10.
string_repr(test_string) assumes the string contains
a 0 character and encodes it as '\\x00'
looking at the function 'PyUnicode_EncodeMBCS(const
Py_UNICODE *p, int size, const char *errors)' there
are basicly two functions
{
mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size,
NULL, 0, NULL, NULL);
repr = PyString_FromStringAndSize(NULL, mbcssize);
}
WideCharToMultiByte returns the nummer of bytes
needed for the buffer, because of the string
termination this functions returns 10.
PyString_FromStringAndSize assumes its second
argument to be the number of needed characters, not
bytes. So an easy fix would be
to change
repr = PyString_FromStringAndSize(NULL, mbcssize);
in
repr = PyString_FromStringAndSize(NULL, mbcssize -
1);
Just checked the 2.4.3 svn trunk and it contains the
same bug.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-02 21:09
Message:
Logged In: YES
user_id=33168
Thanks for letting us know. Closing as requested.
--
Comment By: Jan-Willem (jwnmulder)
Date: 2006-08-02 10:44
Message:
Logged In: YES
user_id=770969
and the result for the xbox
10
101 110 99 111 100 101 32 109 101 0
11
101 110 99 111 100 101 32 109 101 0 0
It seems the xbox calculates an extra character for a '\0'
count(L"encode me", -1);
results on both platforms in ret = 10
So I think this bug can be closed and clasified as an xbox
bug... Not so hard for us to fix, almost all api calls for
dlls are emulated in our application, so it is easy enough
to put a fix in for us.
--
Comment By: Hirokazu Yamamoto (ocean-city)
Date: 2006-08-01 22:31
Message:
Logged In: YES
user_id=1200846
I think this is not related to that patch.
On my win2000sp4, teminating null character is not passed to
PyUnicode_EncodeMBCS.
//
// patch for debug (release24-maint branch)
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 51033)
+++ Objects/unicodeobject.c (working copy)
@@ -2782,6 +2782,20 @@
char *s;
DWORD mbcssize;
+{ /* debug */
+
+int i;
+
+printf("> %d\n", size);
+
+for (i = 0; i < size; ++i) {
+ printf("%d ", (int)p[i]);
+}
+
+printf("\n");
+
+} /* debug */
+
/* If there are no characters, bail now! */
if (size==0)
return PyString_FromString("");
//
// a.py
test_string = 'encode me'
print repr(test_string.encode('mbcs'))
//
// result
R:\>py a.py
> 9
101 110 99 111 100 101 32 109 101
'encode me'
[7660 refs]
And I tried this.
#include
#include
#include
void count(LPCWSTR w, int size)
{
char *buf; int i;
const int ret = ::WideCharToMultiByte(
CP_ACP,
0,
w,
size,
NULL,
0,
NULL,
NULL
);
if (ret == 0)
{
printf("error\n");
}
else
{
printf("%d\n", ret);
}
buf = (char*)malloc(ret);
::WideCharToMultiByte(
CP_ACP,
0,
w,
size,
buf,
ret,
NULL,
NULL
);
for (i = 0; i < ret; ++i)
{
printf("%d ", (int)buf[i]);
}
printf("\n");
free(buf);
}
int main()
{
count(L"encode me", 9);
count(L"encode me", 10); /* include null charater */
}
/*
9
101 110 99 111 100 101 32 109 101
10
101 110 99 111 100 101 32 109 101 0
*/
As stated in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp
, WideCharToMultiByte never output null character if source
string doesn't contain
[ python-Bugs-1531405 ] format_exception raises if str(exception) raises
Bugs item #1531405, was opened at 2006-07-30 14:06 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Jp Calderone (kuran) >Assigned to: Neal Norwitz (nnorwitz) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current [EMAIL PROTECTED] that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. -- Comment By: Jp Calderone (kuran) Date: 2006-08-02 15:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> -- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 15:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files
Bugs item #1532483, was opened at 2006-08-01 14:52 Message generated for change (Comment added) made by madewokherd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Vincent Povirk (madewokherd) Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. -- >Comment By: Vincent Povirk (madewokherd) Date: 2006-08-03 05:17 Message: Logged In: YES user_id=553355 It does, and that's what I've been doing. I can't believe I failed to mention it. -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 13:28 Message: Logged In: YES user_id=44345 Vincent, A simple workaround would be to define a fully quoting dialect: class quoted_excel(csv.excel): quoting=csv.QUOTE_NONNUMERIC # or QUOTE_ALL That would cause your generated CSV files to start with a quote character, e.g.: "ID","FOO" 1,"bar" 2,"bAz" Try that and see if it makes Excel 2003 happy. Skip -- Comment By: Vincent Povirk (madewokherd) Date: 2006-08-01 18:01 Message: Logged In: YES user_id=553355 Thanks for your response. Yes, it's definitely a bug in Excel 2003 (as it also complains about files it saved). I do not have a later version of Excel to test. Microsoft has a page about this issue that seems to say 2003 is the last version with that problem: http://support.microsoft.com/kb/323626/ Their solution is worse than the problem, I'd be interested in seeing how a later version behaves. I know that if the first cell is quoted, Excel will open it without complaining. I think the best solution would be to quote the first cell if it starts with ID by introducing a new QUOTE_ constant. I don't know how that part of the code works (I'm too lazy to read things that aren't written in python); maybe it's more reasonable to quote any field starting with ID. I don't know of any other uses that would break, but I'm not in touch with many csv users. -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 16:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1191458 ] [AST] Failing tests
Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 9 Submitted By: Brett Cannon (bcannon) >Assigned to: Neal Norwitz (nnorwitz) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-02 22:59 Message: Logged In: YES user_id=33168 Fix pending. -- Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 08:31 Message: Logged In: YES user_id=31392 Just wanted to note that I have fixes for the failing tests on my laptop. Need to sync with the current trunk before I can check in. -- Comment By: Brett Cannon (bcannon) Date: 2005-10-25 15:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-23 21:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. -- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. -- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_war
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 01:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-02 23:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? -- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 07:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. -- Comment By: Jan Palus (atler_) Date: 2006-04-17 11:50 Message: Logged In: YES user_id=1497957 /me confirms -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 08:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? -- Comment By: Jan Palus (atler_) Date: 2006-04-15 07:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 00:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. -- Comment By: nomind (vnainar) Date: 2006-04-13 04:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 22:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? -- Comment By: nomind (vnainar) Date: 2006-04-10 22:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 15:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). -- Comment By: Jan Palus (atler_) Date: 2006-04-10 14:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Some
[ python-Bugs-1531405 ] format_exception raises if str(exception) raises
Bugs item #1531405, was opened at 2006-07-30 21:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current [EMAIL PROTECTED] that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 06:13 Message: Logged In: YES user_id=849994 I have a fix and will apply as soon as trunk is unfrozen. -- Comment By: Jp Calderone (kuran) Date: 2006-08-02 22:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> -- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 22:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
