[ python-Bugs-1677694 ] test_timeout refactoring
Bugs item #1677694, was opened at 2007-03-10 01:49 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout refactoring Initial Comment: Please see #728815. https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470 -- >Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-03-10 15:39 Message: Logged In: YES user_id=51702 Originator: YES But the bugfix is so simple. :) The original author Dmitry Vasiliev claimed that connecting to www.google.com with port 80 did not always work for him because of a transparent proxy. I believe what he meant was that connection was not guaranteed to timeout. So he changed the port to 21 which www.google.com does not respond to. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 04:39 Message: Logged In: YES user_id=1344176 Originator: NO In a comment on patch #728815, you (Bjorn) said, "[p]lus, (I think) it fixes a bug which (I think) only happens when you access the internet from behind a web proxy." Could you split any bug fixes into a patch separate from the code cleanup and refactoring? That will make reviewing it/them easier. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1677694&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor
Bugs item #1595742, was opened at 2006-11-13 11:54 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 09:44 Message: Logged In: YES user_id=1344176 Originator: NO Fixed by applying patch #1599845 as r54262. Thanks for your bug report! -- Comment By: Peter Parente (parente) Date: 2006-11-20 12:16 Message: Logged In: YES user_id=624776 Originator: YES Submitted as patch #1599845 in patch tracker. -- Comment By: Peter Parente (parente) Date: 2006-11-20 12:07 Message: Logged In: YES user_id=624776 Originator: YES The SimpleXMLRPCServer class in SVN HEAD now has allow_reuse_address set to True by default. This mimics the implementation of the BaseHTTPServer class which also has it set to True. Therefore, this patch should probably not concentrate on just making allow_reuse_address flag accessible on instances via __init__. Instead, the patch should probably be for TCPServer and specify whether server_bind and server_activate are called automatically or not by the constructor. The default behavior will remain the same as it is now. Specifying False on this flag will allow a developer to set the various variables on a TCPServer server instance before invoking bind/activate manually. -- Comment By: Peter Parente (parente) Date: 2006-11-16 22:28 Message: Logged In: YES user_id=624776 Originator: YES Will do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 12:34 Message: Logged In: YES user_id=849994 Originator: NO Would you want to work on a patch for this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&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 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. -- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? -- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&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 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-10 18:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun -- Comment By: James Lick (jlick) Date: 2007-03-10 17:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. -- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? -- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672332 ] cPickle can pickle, but cannot unpickle on 64bit machines
Bugs item #1672332, was opened at 2007-03-02 12:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bartlomiej Ogryczak (oneg) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle can pickle, but cannot unpickle on 64bit machines Initial Comment: Seems that on 64-bit machines cPickle is able to pickle floats smaller then DBL_MIN, but it's unable to unpickle them. 64-bit machine (Solaris 10 on Sparc) Python 2.4.4 (#1, Oct 26 2006, 10:01:37) [GCC 3.3.4] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F9.9694e-311\n.' >>> cPickle.loads(_) Traceback (most recent call last): File "", line 1, in ? ValueError: could not convert string to float Same thing works fine on 32-bit machine (P4 with MS Windows) Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cPickle >>> cPickle.dumps(1e-310) 'F0\n.' >>> -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-10 18:09 Message: Logged In: YES user_id=21627 Originator: NO If python is a 32-bit binary, it should be completely irrelevant that the processor is a 64-bit processor. Python can't tell the difference. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 22:46 Message: Logged In: YES user_id=849994 Originator: NO I seem to remember that float pickling has been overhauled for 2.5, could you try with a 2.5 Python and report the results? -- Comment By: Bartlomiej Ogryczak (oneg) Date: 2007-03-05 17:49 Message: Logged In: YES user_id=1733256 Originator: YES I forgot to specify, it's 32-bit Python binary. I'm guessing yours is 64-bit binary on 64-bit system? Some additional info: gcc --version gcc (GCC) 3.3.4 $ file `which python` ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped $ ldd `which python` libresolv.so.2 =>/usr/lib/libresolv.so.2 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 =>/usr/lib/librt.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libstdc++.so.5 =>/usr/local/lib/libstdc++.so.5 libm.so.2 => /usr/lib/libm.so.2 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libmd5.so.1 => /usr/lib/libmd5.so.1 libscf.so.1 => /usr/lib/libscf.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libdoor.so.1 => /usr/lib/libdoor.so.1 libuutil.so.1 => /usr/lib/libuutil.so.1 /platform/SUNW,Sun-Fire-15000/lib/libc_psr.so.1 /platform/SUNW,Sun-Fire-15000/lib/libmd5_psr.so.1 -- Comment By: Santiago Gala (sgala) Date: 2007-03-05 17:38 Message: Logged In: YES user_id=178886 Originator: NO FYI: it doesn't happen for me in python 2.4.3, 2.5svn and 2.6svn built on linux (x86_64) with gcc-4.1.2, so it looks compiler version or hw platform specific. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672332&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result
Bugs item #1528074, was opened at 2006-07-25 03:59 Message generated for change (Comment added) made by rtvd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&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 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. -- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled
Bugs item #1516995, was opened at 2006-07-04 14:34 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&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 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 -- >Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 17:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 20:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? -- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 04:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-633930 ] Nested class __name__
Bugs item #633930, was opened at 2002-11-05 12:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&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: None >Status: Closed Resolution: None Priority: 3 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Nested class __name__ Initial Comment: The __name__ attribute of a nested class should be set to 'outer.inner', both for classic and for new-style classes. E.g. >>> class C: ... class C1: pass ... >>> C.C1.__name__ 'C.C1' >>> -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-10 13:21 Message: Logged In: YES user_id=6380 Originator: YES I don't think so. Closing. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 02:22 Message: Logged In: YES user_id=849994 Originator: NO Any interest for Python 3000 on this? Otherwise we can close it. -- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I'm less sure I even want this now, and not at all sure how to do it any more, so lowering priority. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-14 18:13 Message: Logged In: YES user_id=6380 Hm, but should this also be done for functions inside classes? E.g. class C: def foo(self): pass assert C.foo.__name__ == "C.foo" assert C.__dict__["foo"].__name__ == "C.foo" And what about classes inside functions? def f(): class C: pass return C assert f().__name__ == "f.C" ??? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=633930&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&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 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 01:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun -- Comment By: James Lick (jlick) Date: 2007-03-11 00:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 16:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. -- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 16:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 15:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? -- Comment By: James Lick (jlick) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actually the build will fail because of the incorrect flag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archi
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&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 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-10 20:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. -- Comment By: James Lick (jlick) Date: 2007-03-10 19:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-10 18:07 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, although you might want to consider AMD64 as well. I think it should be -KPIC (although I'm uncertain whether Python works on that system at all). See http://blogs.sun.com/x86be/category/Sun -- Comment By: James Lick (jlick) Date: 2007-03-10 17:14 Message: Logged In: YES user_id=673069 Originator: NO I'm willing to take a stab at a patch. I've reviewed the Sun Studio 11 documentation and it appears that the preferred options are: Sun cc Sparc: -xcode=pic32 Sun cc X86: -Kpic Does that match the way you read it, loewis? -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 09:56 Message: Logged In: YES user_id=21627 Originator: NO I don't want to make a change now, just to have to deal with a bug report two years from now which then will sit again in this tracker for years again. I'm fine with documenting that older SunPRO compilers are not supported; -xcode has been supported atleast since Sun Forte 6 (released in 2000); earlier products had reached their end-of-life long ago. So either this gets fixed properly now, or not at all. -- Comment By: Carson Gaspar (cgaspar) Date: 2007-03-09 09:06 Message: Logged In: YES user_id=664506 Originator: YES While the doc labels the -KPIC option as "obsolete" for SPARC, it works fine. Perhaps Studio 12 will break it, but all current compilers understand it fine. If you want to be pedantically correct and use -xcode=pic32, you don't need an architecture test, you need to actually _try_ the option, as older SPARC compilers won't accept it either. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-09 08:08 Message: Logged In: YES user_id=21627 Originator: NO One problem is that the proposed change is incorrect. According to the C User's Guide of Sun Studio 11 (document 819-3688-10), -KPIC is an obsolete option on SPARC, and should be replaced with -xcode=pic32 (section A.1.15). So I think a patch should be architecture-specific. Can somebody come up with a patch that does that? -- Comment By: James Lick (jlick) Date: 2007-03-07 09:34 Message: Logged In: YES user_id=673069 Originator: NO Perhaps I was unclear in bug #1561333 that this resulted in only a warning. Actu
[ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled
Bugs item #1516995, was opened at 2006-07-04 10:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&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 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 15:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 12:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 15:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? -- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 00:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678102 ] zlib.crc32() not cross-platform
Bugs item #1678102, was opened at 2007-03-10 15:07
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=1678102&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
Private: No
Submitted By: Ben Collver (bencollver)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib.crc32() not cross-platform
Initial Comment:
The zlib.crc32() function sometimes produces different results for the same
input on big and little-endian processors. Same for zlib.adler32().
sparc64:
>>> import zlib
>>> print zlib.adler32("--", 1)
> 3763407051
>>> print zlib.crc32("--", 1)
3044228349
i386:
>>> import zlib
>>> print zlib.adler32("--", 1)
> -531560245
>>> print zlib.crc32("--", 1)
-1250738947
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678102 ] zlib.crc32() not cross-platform
Bugs item #1678102, was opened at 2007-03-10 15:07
Message generated for change (Comment added) made by bencollver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&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
Private: No
Submitted By: Ben Collver (bencollver)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib.crc32() not cross-platform
Initial Comment:
The zlib.crc32() function sometimes produces different results for the same
input on big and little-endian processors. Same for zlib.adler32().
sparc64:
>>> import zlib
>>> print zlib.adler32("--", 1)
> 3763407051
>>> print zlib.crc32("--", 1)
3044228349
i386:
>>> import zlib
>>> print zlib.adler32("--", 1)
> -531560245
>>> print zlib.crc32("--", 1)
-1250738947
--
>Comment By: Ben Collver (bencollver)
Date: 2007-03-10 15:13
Message:
Logged In: YES
user_id=778667
Originator: YES
The extra > characters before the first results come from me pasting the
results to my irc client, then copying from there and pasting here. Sorry
for any confusion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678102&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled
Bugs item #1516995, was opened at 2006-07-04 14:34 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&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 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 -- >Comment By: Vinay Sajip (vsajip) Date: 2007-03-11 00:58 Message: Logged In: YES user_id=308438 Originator: NO Thanks for the info. test2() is a little sensitive because it makes assumptions about the state of handlers attached to the root logger. test4() and test5() do some slightly dodgy manipulation of the internal handler list maintained by the module. I played around with the assumption that test5() is the culprit (as it's the last test run), and found that adding the lines hdlr = logging.getLogger().handlers[0] logging.getLogger().handlers.remove(hdlr) in test5(), just after the line os.remove(fn) causes the error not to occur, and the test passes successfully. Please try this on your system and re-run the tests, and if you can confirm that this change works for you, I can check it in. (I propose to only check it into trunk, and not into release25-maint or other branches - what do you think?) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 20:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 17:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHandlers created either explicity in test_logging.py or via the calls to fileConfig(), to see which StreamHandler is not being released. TIA... -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 20:42 Message: Logged In: YES user_id=1344176 Originator: YES Still present as of 54248. Vinay, do you have any insights on this? -- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 04:03 Message: Logged In: YES user_id=1344176 This issue is still present as of r51654. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&group_id=5470
[ python-Bugs-902172 ] Timezone miscalculation (time.mktime)
Bugs item #902172, was opened at 2004-02-22 17:09
Message generated for change (Comment added) made by pboddie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&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.3
Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Marti (sipsick)
Assigned to: Brett Cannon (bcannon)
Summary: Timezone miscalculation (time.mktime)
Initial Comment:
The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)
Python seems to miscalculate the local time when using
mktime. The problem appeared when one of the runtests
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)
I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1,
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release)
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3
20040110 (prerelease) (Debian)]
Both machine generate the identical error:
AssertionError: Expected '1#1970-01-06 00:00:00#1' in:
1#1970-01-05 23:00:00#1 [...]
A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
('EET', 'EEST')
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0
However, the only difference between the Linux and BSD
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0
I also attached the results of the moin test just in case.
--
Marti
--
Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 02:28
Message:
Logged In: YES
user_id=226443
Originator: NO
Belated comment for posterity: this looks like a DST "inversion" problem -
the system zone information may have been incorrect causing the system to
believe that the Epoch occurred in a DST period.
--
Comment By: Marti (sipsick)
Date: 2004-02-24 23:52
Message:
Logged In: YES
user_id=345221
Summary: This doesn't look like Python's fault. case closed.
bcannon wrote:
> In other words, EET is two hours ahead of UTC normally and
only
> one hour ahead during daylight savings).
That is not exactly correct.
EET (Eastern European Time, in winter) is UTC+2h, and
EEST (Eastern European Summer Time) is UTC+3h (This is
DST)
Reference: http://www.timeanddate.
com/library/abbreviations/timezones/eu/eet.html
The way I understand it, daylight should be 0 not 1. (DST
hasn't begun yet.
Reference: http://www.timeanddate.com/worldclock/city.html?
n=242
Otherwise you're right: it's not even Python's fault! I got
exactly the same results on my Linux machine when I tested it
in C. So I suppose this case is closed.
struct tm format: {sec, min, hour, mday, mon, year, wday,
yday, isdst}
daylight = 1
timezone = -7200
tzname = {"EET", "EEST"}
mktime(localtime(0)) = 0
mktime(gmtime(0)) - timezone = -3600
gmtime(0) = {0, 0, 0, 1, 0, 70, 4, 0, 0}
mktime({0, 0, 0, 1, 0, 70, 4, 0, 0}) - timezone = -3600
mktime({0, 0, 0, 1, 0, 70, 4, 0,-1}) - timezone = -3600
mktime({0, 0, 0, 1, 0, 70, 4, 0, 1}) - timezone = -3600
I attached the code of mktime.c just in case anybody would
want to review it.
--
Comment By: Brett Cannon (bcannon)
Date: 2004-02-24 09:36
Message:
Logged In: YES
user_id=357491
OK, what I need is the result for ``time.localtime(0)`` (according to the
calculations above should be three hours ahead of UTC, but in actuality,
as long as the DST field is 0, should only be two hours ahead for EET)
and ``time.mktime(time.gmtime(0))`` (should be -10800 according to
the calculations above, but I want to double-check). And the value of
``time.altzone`` wouldn't hurt for trying to deal with the slight
difference between the two OSs (should be -3600, or 1 hour ahead of
UTC, for DST in EET, right? In other words, EET is two hours ahead of
UTC normally and only one hour ahead during daylight savings).
It looks like time.localtime(0) is off by an hour for some odd reason.
And as for the discrepency between platforms, it should be only an hour
difference since you should be subtracting time.altzone with the DST flag
set to 1 and not time.timezone . So it looks like Linux is behaving
correctly and NetBSD is being really screwy if that is th
[ python-Bugs-1635217 ] Little mistake in docs
Bugs item #1635217, was opened at 2007-01-14 07:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635217&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 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Nobody/Anonymous (nobody) Summary: Little mistake in docs Initial Comment: It would be nice to see example of setup() call on the page with "requires" keywords argument description http://docs.python.org/dist/node10.html Like: setup(..., requires=["somepackage (>1.0, !=1.5)"], provides=["mypkg (1.1)"] ) There seems to be mistake in table with examples for "provides" keyword on the same page - it looks like: mypkg (1.1 shouldn't this be mypkg (1.1)? -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-10 19:33 Message: Logged In: YES user_id=33168 Originator: NO Anatoly, if you could create the doc in plain text, we could add it. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-18 21:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. I fixed the unbalanced paren. I'll leave this open in case someone is ambitious to add more doc. Committed revision 53487. (2.5) Committed revision 53488. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635217&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled
Bugs item #1516995, was opened at 2006-07-04 10:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1516995&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 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- : Traceback (most recent call last): File "Lib/test/regrtest.py", line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File "Lib/test/regrtest.py", line 673, in dash_R run_the_test() File "Lib/test/regrtest.py", line 660, in run_the_test indirect_test() File "/home/collin/src/python/Lib/test/test_support.py", line 299, in inner return func(*args, **kwds) File "/home/collin/src/python/Lib/test/test_logging.py", line 677, in test_main test_main_inner() File "/home/collin/src/python/Lib/test/test_logging.py", line 640, in test_main_inner globals()['test%d' % t]() File "/home/collin/src/python/Lib/test/test_logging.py", line 347, in test2 sh.close() File "/home/collin/src/python/Lib/logging/__init__.py", line 687, in close del _handlers[self] KeyError: This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 00:53 Message: Logged In: YES user_id=1344176 Originator: YES Adding those lines does indeed suppress the exception. I'm not convinced it eliminates the problem, though, since adding "t = 2" after "for t in range(1,6):" in test_main_inner() will still cause test2() to raise KeyError() (with the same traceback as before), even with your patch. I've tried this same approach for all tests (0-5) and test2() is the only one to exhibit this behaviour. That said, I'm very happy to have test_logging not fail under "regrtest -R" anymore : ) I would apply your solution to both trunk/ and release25-maint/, if only to keep the number of buildbot false alarms to a minimum. Thanks, Vinay! -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 19:58 Message: Logged In: YES user_id=308438 Originator: NO Thanks for the info. test2() is a little sensitive because it makes assumptions about the state of handlers attached to the root logger. test4() and test5() do some slightly dodgy manipulation of the internal handler list maintained by the module. I played around with the assumption that test5() is the culprit (as it's the last test run), and found that adding the lines hdlr = logging.getLogger().handlers[0] logging.getLogger().handlers.remove(hdlr) in test5(), just after the line os.remove(fn) causes the error not to occur, and the test passes successfully. Please try this on your system and re-run the tests, and if you can confirm that this change works for you, I can check it in. (I propose to only check it into trunk, and not into release25-maint or other branches - what do you think?) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 15:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then "-R ::" kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the "sh" handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: "-R ::" doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 12:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-(, without which the -R option is not available to me. Also, of course, it's not a bug in logging itself, more in the test case. If you have time, I would appreciate some help on this: I would temporarily modify test_logging to print out the StreamHa
