Ismail Donmez added the comment:
This works fine with python 2.4 :
import locale
locale.setlocale(locale.LC_ALL,tr_TR.UTF-8)
'tr_TR.UTF-8'
print uMayıs.upper()
MAYIS
--
nosy: +cartman
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Ismail Donmez added the comment:
@George,
i.upper() WILL be I-with-a-dot-above in Turkish.i
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
_
___
Python-bugs-list
Ismail Donmez added the comment:
There is no need to unassign this, the bug is invalid.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
_
___
Python-bugs-list
New submission from Ismail Donmez:
As reported at
http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065826.html
. There is an integer overflow in imageop module which results in an
interpreter crash. Original proof of concept code is attached.
--
components: Library (Lib
Ismail Donmez ism...@namtrac.org added the comment:
Problem seems to be in _ctypes_test.c . If you compile _ctypes_test.c with gcc
problems disappears.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9852
Ismail Donmez ism...@namtrac.org added the comment:
No interesting option. But this looks like a clang bug, compiling
_ctypes_test.c with -O0 fixes the issue. So this is a compiler optimization bug.
--
___
Python tracker rep...@bugs.python.org
http
New submission from Ismail Donmez ism...@namtrac.org:
Using py3k r87206 on Mac OSX 10.6.5,
[~/Sources/py3k] make testall
running build
running build_ext
building dbm using ndbm
Python build finished, but the necessary bits to build these modules were not
found:
_gdbm ossaudiodev
Ismail Donmez ism...@namtrac.org added the comment:
Patch works fine on Mac OSX 10.6.5
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10453
New submission from Ismail Donmez ism...@namtrac.org:
clang (as with gcc 4.x) assumes signed integer overflow is undefined. But
Python depends on the fact that signed integer overflow wraps.
Currently configure script adds -fwrapv flag for GCC (added by me back in the
day), same should
Ismail Donmez ism...@namtrac.org added the comment:
Currently test_overflow inside test_list fails without this patch. Is that good
enough or should we create a specific test?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ismail Donmez ism...@namtrac.org added the comment:
This is only reproducable with clang 2.9 trunk builds due to new optimizations.
Also note that clang commits confirm that -fwrapv must be provided if you
assume signed integer overflow wraps. This was also the case with a spec test.
I tested
Ismail Donmez ism...@namtrac.org added the comment:
I think the patch is good to go, any comments/questions ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11149
Ismail Donmez ism...@namtrac.org added the comment:
@Antoine Pitrou , that is tracked by http://bugs.python.org/issue1621
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11149
Ismail Donmez added the comment:
Guido,
The poc is taken as is, sorry.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1179
__
___
Python-bugs-list mailing list
Unsubscribe
Ismail Donmez added the comment:
nevyn: Your patch cleanly applies to python 2.4.4 and fixes the
interpreter crash with poc.py
Thanks.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1179
Ismail Donmez added the comment:
gdb backtrace, segfaulting test is Lib/test/test_str.py
Added file: http://bugs.python.org/file8936/backtrace.txt
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
__(gdb) run ./Lib
Changes by Ismail Donmez:
--
title: Regression tests crashes with gcc 4.3 - test_str.py crashes
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
__
___
Python-bugs
New submission from Ismail Donmez:
Using python 2.5 revision 59479 from release25-maint branch,
[~/python-2.5] LD_LIBRARY_PATH=/home/cartman/python-2.5: ./python
./Lib/test/test_re.py
test_anyall (__main__.ReTests) ... ok
test_basic_re_sub (__main__.ReTests) ... ok
test_bigcharset (__main__
New submission from Ismail Donmez:
Checkout Python 2.5 from release25-maint branch, revision 59479
Compiled with gcc 4.3.0 20071212 , make test crashes with the following
output
[... snip ...]
test_socket_ssl
test_socket_ssl skipped -- Use of the `network' resource not enabled
New submission from Ismail Donmez:
Checkout Python 2.5 from release25-maint branch, revision 59479,
[~/python-2.5] LD_LIBRARY_PATH=/home/cartman/python-2.5: ./python
./Lib/test/test_socket.py
testCrucialConstants (__main__.GeneralModuleTests) ... ok
testDefaultTimeout (__main__
Ismail Donmez added the comment:
Then it won't run as expected (I got python 2.4 installed system wise) :
./python: error while loading shared libraries: libpython2.5.so.1.0:
cannot open shared object file: No such file or directory
__
Tracker [EMAIL PROTECTED
Ismail Donmez added the comment:
gcc 4.3, Linux 2.6.18, 32bit.
Without LD_LIBRARY_PATH it would use the system libraries and not the
compiled ones which anyway is not wanted.
Configure line used is (damn I forgot to specify this before, sorry)
--with-fpectl \
--enable-shared \
--enable-ipv6
Ismail Donmez added the comment:
--enable-pydebug fixes the crash it might be that some uninitialized
variable doesn't take affect unless optimized as valgrind output shows
many of this.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
Ismail Donmez added the comment:
This is a soon to be released GCC though I won't deny it has
regressions, but note that extra optimizations already uncovered bugs in
other software.
And unless I can get a minimal C testcase, GCC bug will be worthless.
Exact crashling call is string_tests.py
Ismail Donmez added the comment:
Indeed you are correct,
'\ta\n\tb'.expandtabs(2147483647)
Program received signal SIGSEGV, Segmentation fault.
string_expandtabs (self=0xb7ba7c60, args=0xb7ba7dec) at
Objects/stringobject.c:3358
3358*q++ = ' ';
(gdb) bt
#0
Ismail Donmez added the comment:
Not quite yet, gcc 4.3 had a big inlining bug that was just corrected
two weeks ago:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
You may have encountered this bug, or another similar one...
Two weeks ago is too old for me, I am using SVN snapshot from
Ismail Donmez added the comment:
Test always prints overflow here, tested with -O3 but here are
interesting overflow warnings that might give a clue , but I think
Cpickle is not involved here, but anyway:
/home/cartman/python-2.5/Modules/cPickle.c: In function 'Unpickler_noload':
/home/cartman
Ismail Donmez added the comment:
Following testcase doesn't print overflow with gcc 4.3 when compiled
with -O3, works with gcc 3.4.6 though.
#include sys/types.h
#include stdio.h
void foo(ssize_t x)
{
if (x = 0) {
if (x+x 0) printf(Overflow\n);
}
}
main()
{
volatile ssize_t x
Ismail Donmez added the comment:
Reported as a gcc bug, http://gcc.gnu.org/PR34454
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
__
___
Python-bugs-list mailing list
Ismail Donmez added the comment:
Ok so this is a code bug according to GCC developers see comment 1 2
at http://gcc.gnu.org/PR34454 .
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
Ismail Donmez added the comment:
-fwrapv fixes the issue, thanks!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Ismail Donmez added the comment:
Looks like -fwrapv is there since gcc 2.95.3 attached patch adds -fwrapv
when debugging disabled, also removes gcc 4.x part from README as it no
longer applies.
Added file: http://bugs.python.org/file8942/fwrapv.patch
__
Tracker
Ismail Donmez added the comment:
After applying patch you need to run autoconf to update configure file
and svn commit afterwards.
Regards,
ismail
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
Ismail Donmez added the comment:
Ok gcc developers say -fwrapv is there since gcc 3.3 so I think its
still fine, if not I will prepare another patch.
Regards.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
Ismail Donmez added the comment:
Attached patch exactly checks if compiler supports -fwrapv otherwise
doesn't use it. Is this ok?
Added file: http://bugs.python.org/file8944/wrap.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
Ismail Donmez added the comment:
Last patch had a grammar error in comment, fix that.
Added file: http://bugs.python.org/file8945/wrap.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1608
__Index: configure.in
Ismail Donmez added the comment:
Removing --with-wctype-functions in total fixes following regression tests,
test_codecs
test_re
test_ucn
test_unicodedata
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
Ismail Donmez added the comment:
Remove test_ucn from the list, it still fails but its for another bug
report.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
__
___
Python
Ismail Donmez added the comment:
Any ideas/comments on how to move forward with this?
Thanks,
ismail
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
__
___
Python-bugs-list
Ismail Donmez added the comment:
Any other thing I can do to debug this?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1610
__
___
Python-bugs-list mailing list
Unsubscribe
Ismail Donmez added the comment:
This was a glibc regression on my side, it can be closed as invalid. Thanks!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1610
__
___
Python
Ismail Donmez added the comment:
Python README says --with-wctype-functions is deprecated and will be
removed in Python 2.6 , I don't think its worth to fix it now. Also test
failures with --with-wctype-functions is seems to be known according to
Google.
What I wonder if removing --with-wctype
Ismail Donmez added the comment:
Indeed there seems to be regressions:
Python 2.4 :
[~] python
Python 2.4.4 (#1, Oct 23 2007, 11:25:50)
[GCC 3.4.6] on linux2
Type help, copyright, credits or license for more information.
import locale
locale.setlocale(locale.LC_ALL,)
'tr_TR.UTF-8'
print
Ismail Donmez added the comment:
Situation is even more complicated, following functions behave
_correctly_ when wctypes is enabled :
print unicode(i).upper()
İ
print unicode().lower()
Following doesn't work even if wctypes is enabled :
print unicode().upper
Ismail Donmez added the comment:
Same here for Pardus Linux, applied the patch without a regression.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1179
__
___
Python-bugs-list
Ismail Donmez added the comment:
So in conclusion,
- Enabling wctypes makes Turkish support work with \u syntax, breaks
unicode()
- Disabling wctypes breaks Turkish support with \u and/or unicode()
Attached test.py tests Turkish corner cases of lower()/upper() . Correct
output is which python
Ismail Donmez added the comment:
Replacing Turkish characters with hex versions in test2.py still results
in UnicodeDecodeError and works with python 2.4.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
Ismail Donmez added the comment:
Ok that was because we had modified default encoding in Lib/site.py to
be utf-8. Sorry!
The only problem left is last 2 conversions in test.py gives wrong
results when wctypes is disabled, that is :
print u\u0069.upper()
should give \u0130 (LATIN CAPITAL
Ismail Donmez added the comment:
But it should be affected by locale, thats the point of locale.setlocale
call. This is how libc's wc functions behave.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
Ismail Donmez added the comment:
Ok then what is the suggested way to get back the Turkish way of doing
upper/lower on i I ?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
Ismail Donmez added the comment:
Hi Martin,
Actually the only problem is how can I get wctype functionality with
8-bit strings, any example is appreciated.
This bug itself is invalid because --with-wctype-functions is
deprecated. But as I said I just hope removing that doesn't regress
Turkish
Ismail Donmez added the comment:
Funnily,
print .encode(iso-8859-9).decode(iso-8859-9).upper()
works, but
print .encode(iso-8859-9).upper().decode(iso-8859-9)
not.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
Ismail Donmez added the comment:
I guess so, I will no longer spam this bug. Thanks for the suggestions.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
__
___
Python-bugs
Ismail Donmez added the comment:
Tried like ,
unicode(iii).encode(iso-8859-9).upper()
doesn't work, I'll ask on python users list. Thanks.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1609
New submission from Ismail Donmez:
Running python 2.5 maintainance branch,
Test code is :
import tarfile
f = file(rnss-3.12_alpha2.tar.bz2, rb)
tar = tarfile.open(fileobj=f, mode=r|bz2)
try:
for m in tar:
tar.extract(m)
finally:
tar.close()
f.close
Changes by Ismail Donmez:
--
type: - behavior
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1718
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Ismail Donmez added the comment:
Argh stupid me, this is due a patch on my side, grr. ı am really sorry.
Please close as invalid :(
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1718
Ismail Donmez added the comment:
-Wstrict-overflow=3 with gcc 4.3 trunk here shows :
Modules/cPickle.c: In function 'Unpickler_noload':
Modules/cPickle.c:4232: warning: assuming signed overflow does not occur
when assuming that (X - c) X is always false
Modules/cPickle.c:194: warning
Ismail Donmez added the comment:
Make sure you use gcc 4.3 trunk and at least -O2 is enabled. I tested
revision 59895 from release25-maint branch.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
FWIW gcc hacker Ian Lance Taylor has a nice article about signed
overflow optimizations in gcc, see http://www.airs.com/blog/archives/120
. Reading that it might be better to use -fno-strict-overflow instead of
-fwrapv.
Regards,
ismail
Ismail Donmez added the comment:
Ian says -fno-strict-overflow still allows some optimizations, and his
example code shows less assembly is produced with -fno-strict-overflow.
But of course your opinion matters on this one, not mine.
Regards,
ismail
__
Tracker
Ismail Donmez added the comment:
FWIW I reported this to GCC bugzilla as a missing diagnostic @
http://gcc.gnu.org/PR34843
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Problem was that -Wall at the end was resetting -Wstrict-overflow, so
here is the current results for signed overflow warnings (python 2.5
branch SVN), a lot of them :
Parser/acceler.c: In function 'fixstate':
Parser/acceler.c:90: warning: assuming signed
Ismail Donmez added the comment:
-Wstrict-overflow=5 is not valid afaik its 1-3, 3 for most verbose also
you need a recent gcc 4.3 snapshot for best results, check your
distribution for gcc-snapshot package.
About the -Wall thing it seems to be a gcc bug, but for now workaround
is easy
Ismail Donmez added the comment:
Replace -fwrapv with -Wstrict-overflow=3 -Werror=strict-overflow when
supported. Guido, does this do what you wanted?
Regards,
ismail
Added file: http://bugs.python.org/file9205/overflow-error.patch
__
Tracker [EMAIL PROTECTED
Changes by Ismail Donmez:
Added file: http://bugs.python.org/file9210/overflow-error4.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing
Ismail Donmez added the comment:
No I mean we need a new unsigned variant. Else we will have to cast it
to unsigned for many overflow cases which is ugly.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Btw I think we need an unsigned version of Py_ssize_t to fix this
problem cleanly. I am not sure if you would agree with me though.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Yes it breaks compilation with gcc 4.3. Fixing these bugs are mostly
s/int/unsigned int. But some parts of code need Python wisdom :/
New patch attached adressing your comment.
Added file: http://bugs.python.org/file9207/overflow-error2.patch
Changes by Ismail Donmez:
Added file: http://bugs.python.org/file9209/overflow-error3.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing
Ismail Donmez added the comment:
I created a git repo for my fixes over
http://repo.or.cz/w/pytest.git?a=shortlog;h=overflow-fix .
Now as tiran suggested I fix one file and make sure nothing regressed.
But! Feel free to beat me to it and fix this. I am all new to this and
progress might
Ismail Donmez added the comment:
With second patch now python builds without any overflow warnings, no
new regressions. Please test and/or review.
Only thing left is fixing Modules subdirectory.
Thanks.
Added file: http://bugs.python.org/file9238/fix-overflows-try2.patch
Ismail Donmez added the comment:
Possibly last one before final patch, only Modules/_sre.c left to fix, I
appreciate help on that. Please ignore tab problems, I think that can be
fixed later on.
Thanks.
Added file: http://bugs.python.org/file9239/fix-overflows-try3.patch
Ismail Donmez added the comment:
Final patch should be complete. Used a trick in _sre.c, instead of i 0
, I used
i + i i to trick gcc.
Added file: http://bugs.python.org/file9242/fix-overflows-final.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Ismail Donmez added the comment:
Hi Christian,
unsigned cast is actually suggested by GCC developers to force correct
wrapping for signed types. And thanks to Martin, it makes sense :-)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Thanks for the through review! I will add -Wsign-compare and fix new
warnings.
Btw current state is with the patch -fwrapv is not needed and no
regressions.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
To Neal,
Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk.
To Guido,
I'll check _csv.c issue closely. Shall I create the new bug reports or
will reviewers will do so and CC me maybe?
__
Tracker [EMAIL
Ismail Donmez added the comment:
_sre.c case is the most interesting one , compiler says :
./Modules/_sre.c:1002: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1069: warning: assuming signed overflow does not occur
when simplifying
Ismail Donmez added the comment:
For xmlparse.c compiler says :
Modules/expat/xmlparse.c:5337: warning: assuming signed overflow does
not occur when simplifying conditional to constant
Its impossible for j to overflow here due to name[i] check but I am not
sure what gcc is optimizing here
Ismail Donmez added the comment:
Hah strlen in a loop, a nice beginner mistake but its 5.30 AM here so
please excuse me, Guido your version of course is way better. But with
that version compiler issues
Modules/_csv.c:969: warning: assuming signed overflow does not occur when
simplifying
Ismail Donmez added the comment:
Moving the empty check before the loop will fix this and possibly
optimize empty string handling.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Guido van Rossum added the comment:
I wonder if it would help making i a Py_ssize_t instead of an int?
gcc still issues the same warning with that.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Neal,
You could btw check
http://repo.or.cz/w/pytest.git?a=shortlog;h=overflow-fix which have each
fix seperate so that reviewing is easy. Just ignore configure changes
thats for later.
Thanks,
ismail
__
Tracker [EMAIL PROTECTED
Ismail Donmez added the comment:
gcc is optimizing the second if check , for specifically i == 0 seems to
redundant according to gcc.
if (i == 0 quote_empty) {
if (dialect-quoting == QUOTE_NONE) {
PyErr_Format(error_obj
Ismail Donmez added the comment:
Any news on this? Also gcc 4.3 gcc 4.2.3 fixed the -Wall clobbering -
Wstrict-overflow problem, which is good news.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
New submission from Ismail Donmez ism...@namtrac.org:
Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+
filesystem.
==
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase
New submission from Ismail Donmez ism...@namtrac.org:
Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+
filesystem.
==
FAIL: test_ucd_510 (test.test_unicodedata.UnicodeMiscTest
New submission from Ismail Donmez ism...@namtrac.org:
Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+
filesystem.
==
ERROR: test_tab_identifiers (tkinter.test.test_ttk.test_widgets.NotebookTest
Ismail Donmez ism...@namtrac.org added the comment:
Yes I did make distclean before building (to cleanup old build files).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9832
Ismail Donmez ism...@namtrac.org added the comment:
Btw I configured with;
./configure --with-wctype-functions --with-fpectl --with-wide-unicode
--with-computed-gotos --enable-ipv6 --with-universal-archs=64-bit
MACOSX_DEPLOYMENT_TARGET=10.6
Ismail Donmez ism...@namtrac.org added the comment:
Btw I configure with;
./configure --with-wctype-functions --with-fpectl --with-wide-unicode
--with-computed-gotos --enable-ipv6 --with-universal-archs=64-bit
MACOSX_DEPLOYMENT_TARGET=10.6
Ismail Donmez ism...@namtrac.org added the comment:
Btw I configured with;
./configure --with-wctype-functions --with-fpectl --with-wide-unicode
--with-computed-gotos --enable-ipv6 --with-universal-archs=64-bit
MACOSX_DEPLOYMENT_TARGET=10.6
Ismail Donmez ism...@namtrac.org added the comment:
Problem is I set PYTHONDONTWRITEBYTECODE to 1, tests should disable this
environmental variable before testing for *.pyc files. Closing as invalid.
--
resolution: - invalid
status: open - closed
Ismail Donmez ism...@namtrac.org added the comment:
Also reproduced on Snow Leopard.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8445
New submission from Ismail Donmez ism...@namtrac.org:
py3k branch, revision 84907
==
ERROR: test_font_eq (tkinter.test.test_tkinter.test_font.FontTest
Ismail Donmez ism...@namtrac.org added the comment:
With Guilherme's patch;
We are down to 1 error but thats a new errror;
test test_ttk_guionly failed -- Traceback (most recent call last):
File /Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py,
line 28
Ismail Donmez ism...@namtrac.org added the comment:
Patch fixes the problem for me, please apply. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8445
Ismail Donmez ism...@namtrac.org added the comment:
Works for me on Snow Leopard for the record.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8445
New submission from Ismail Donmez ism...@namtrac.org:
py3k r86351,
==
FAIL: test_garbage_at_shutdown (__main__.GCTests)
--
Traceback (most recent call last
Changes by Ismail Donmez [EMAIL PROTECTED]:
--
nosy: +cartman
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4561
___
___
Python-bugs-list mailing list
1 - 100 of 189 matches
Mail list logo
