[ python-Bugs-1544381 ] Bad result of calculation
Bugs item #1544381, was opened at 2006-08-22 09:15 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=1544381&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: Performance Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Christophe BERTOLINI (jbertoli) Assigned to: Nobody/Anonymous (nobody) Summary: Bad result of calculation Initial Comment: In the Python Shell enter: >>> 3.84-4.5 -0.66014 The last digits of the calculation result are wrong -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544306 ] checking size of int... configure: error: cannot compute siz
Bugs item #1544306, was opened at 2006-08-22 00:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&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.4 Status: Open Resolution: None Priority: 5 Submitted By: arrecostao (arrecostao) Assigned to: Nobody/Anonymous (nobody) Summary: checking size of int... configure: error: cannot compute siz Initial Comment: Getting multiple error messages when using ./configure # uname -a SunOS cromagnon 5.10 Generic i86pc i386 i86pc # ./configure checking MACHDEP... sunos5 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ 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 gcc... 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 object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for AIX... no checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether c++ also accepts flags for thread support... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... no checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking thread.h usability... no checking thread.h presence... yes configure: WARNING: thread.h: present but cannot be compiled configure: WARNING: thread.h: check for missing prerequisite headers? configure: WARNING: thread.h: see the Autoconf documentation configure: WARNING: thread.h: section "Present But Cannot Be Compiled" configure: WARNING: thread.h: proceeding with the preprocessor's result configure: WARNING: thread.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for thread.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/audioio.h usability... yes checking sys/audioio.h presence... yes checking for sys/audioio.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/loadavg.h usability... yes checking sys/loadavg.h presence... yes checking for sys/l
[ python-Bugs-1544381 ] Bad result of calculation
Bugs item #1544381, was opened at 2006-08-22 07:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&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: Performance Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jean-Christophe BERTOLINI (jbertoli) Assigned to: Nobody/Anonymous (nobody) Summary: Bad result of calculation Initial Comment: In the Python Shell enter: >>> 3.84-4.5 -0.66014 The last digits of the calculation result are wrong -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 08:20 Message: Logged In: YES user_id=849994 This is due to how floats work. See http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544106 ] test_anydbm segmentation fault
Bugs item #1544106, was opened at 2006-08-21 14:02 Message generated for change (Comment added) made by cspence You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Nobody/Anonymous (nobody) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. -- >Comment By: Clay Spence (cspence) Date: 2006-08-22 09:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 19:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544106 ] test_anydbm segmentation fault
Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) >Assigned to: Gregory P. Smith (greg) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 06:45 Message: Logged In: YES user_id=33168 Yes, correct. 4.2.52 is the version of the C BSD DB library. That's a fairly old version. I believe the bug is in there. If you update to 4.3.x or 4.4.x, I suspect the problem will go away. I know very little about bsddb. The code looks quite simple. Assigning Greg as he's probably the only one that has a chance of knowing. -- Comment By: Clay Spence (cspence) Date: 2006-08-22 06:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Bugs item #1544339, was opened at 2006-08-21 21:28 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&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: Case Van Horsen (casevh) >Assigned to: Thomas Heller (theller) Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Initial Comment: The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544762 ] x!=y and [x]==[y] (!)
Bugs item #1544762, was opened at 2006-08-22 19:51 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=1544762&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex ([EMAIL PROTECTED]) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342
Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&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.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 -- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 16:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342
Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&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.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 -- >Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 17:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 16:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342
Bugs item #1542308, was opened at 2006-08-17 22:56 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&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.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 -- >Comment By: Phillip J. Eby (pje) Date: 2006-08-22 22:23 Message: Logged In: YES user_id=56214 Bob, the problem Guido is pointing out is that to run the finally clauses, we have to resume the generator with the RuntimeError thus generated. So it doesn't terminate the loop, because the RuntimeError is effectively raised at the point where the yield occurs. So, in order to run finally clauses sanely after a close() attempt, we would have to prevent such loops. That doesn't mean Guido's example is valid as such; but I think it's possible to accidentally create quasi-indefinite loops using infinite iterators written prior to Python 2.5, if you had a try/except block that was expecting to catch something *other* than GeneratorExit or RuntimeError. So, the net effect would be an unintended hang, if we tried to support retrying until the generator can be closed. Regarding the GC second attempt, this behavior is actually exactly as-specified by the PEP's pseudo-code explanation of how close() is handled. A RuntimeError raised from close() does *not* close the generator; it specifically indicates that the generator has not in fact closed. At this point, after re-reading the PEP and looking at what the code is doing, it's clear that the behavior is "as specified", so the title of the bug is incorrect: the behavior is exactly as specified by PEP 342. So, the rest of my comments below are regarding whether PEP 342 should be changed. And really, the question there is whether it's sane to attempt heroic measures in order to run finally clauses in a generator whose code is *known* to be buggy. The RuntimeError basically says, "this generator is broken", and the GC also tries a second time to close it. If two close attempts don't close it, it's a dead duck. What other measures can we sanely add? We could try forcing the RuntimeError into the generator itself, but then we have to deal with the infinite loop possibility, and the oddities involved in getting to a language specification that can be implemented for Jython, IronPython, etc. On the whole, I think that we probably reached the right balance the first time around: a broken generator should not be allowed to handle the error of its own brokenness. -- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 21:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 20:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342
Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&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.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 -- >Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 18:30 Message: Logged In: YES user_id=139309 It seems that the infinite loop would be the right thing to do, given that's what would happen in a similarly broken __del__ (or anywhere else). -- Comment By: Phillip J. Eby (pje) Date: 2006-08-22 18:23 Message: Logged In: YES user_id=56214 Bob, the problem Guido is pointing out is that to run the finally clauses, we have to resume the generator with the RuntimeError thus generated. So it doesn't terminate the loop, because the RuntimeError is effectively raised at the point where the yield occurs. So, in order to run finally clauses sanely after a close() attempt, we would have to prevent such loops. That doesn't mean Guido's example is valid as such; but I think it's possible to accidentally create quasi-indefinite loops using infinite iterators written prior to Python 2.5, if you had a try/except block that was expecting to catch something *other* than GeneratorExit or RuntimeError. So, the net effect would be an unintended hang, if we tried to support retrying until the generator can be closed. Regarding the GC second attempt, this behavior is actually exactly as-specified by the PEP's pseudo-code explanation of how close() is handled. A RuntimeError raised from close() does *not* close the generator; it specifically indicates that the generator has not in fact closed. At this point, after re-reading the PEP and looking at what the code is doing, it's clear that the behavior is "as specified", so the title of the bug is incorrect: the behavior is exactly as specified by PEP 342. So, the rest of my comments below are regarding whether PEP 342 should be changed. And really, the question there is whether it's sane to attempt heroic measures in order to run finally clauses in a generator whose code is *known* to be buggy. The RuntimeError basically says, "this generator is broken", and the GC also tries a second time to close it. If two close attempts don't close it, it's a dead duck. What other measures can we sanely add? We could try forcing the RuntimeError into the generator itself, but then we have to deal with the infinite loop possibility, and the oddities involved in getting to a language specification that can be implemented for Jython, IronPython, etc. On the whole, I think that we probably reached the right balance the first time around: a broken generator should not be allowed to handle the error of its own brokenness. -- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 17:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 16:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=154
[ python-Bugs-1544762 ] x!=y and [x]==[y] (!)
Bugs item #1544762, was opened at 2006-08-22 17:51 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex ([EMAIL PROTECTED]) -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 22:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342
Bugs item #1542308, was opened at 2006-08-17 22:56 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&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.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 -- >Comment By: Phillip J. Eby (pje) Date: 2006-08-22 22:51 Message: Logged In: YES user_id=56214 You'll need to propose a patch to PEP 342 to alter the specification, then, and get it past Python-Dev. Personally, I don't think that changing the spec is the right thing to do for 2.5. But irrespective of those procedural matters, your __del__ analogy is flawed on two points. First, we do not re-run a __del__ method to handle an error that was raised by that __del__ method! Second, if a generator contains an infinite, non-yielding loop, then of course it will loop forever. So __del__ does not provide any actually useful guidance here. -- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 22:30 Message: Logged In: YES user_id=139309 It seems that the infinite loop would be the right thing to do, given that's what would happen in a similarly broken __del__ (or anywhere else). -- Comment By: Phillip J. Eby (pje) Date: 2006-08-22 22:23 Message: Logged In: YES user_id=56214 Bob, the problem Guido is pointing out is that to run the finally clauses, we have to resume the generator with the RuntimeError thus generated. So it doesn't terminate the loop, because the RuntimeError is effectively raised at the point where the yield occurs. So, in order to run finally clauses sanely after a close() attempt, we would have to prevent such loops. That doesn't mean Guido's example is valid as such; but I think it's possible to accidentally create quasi-indefinite loops using infinite iterators written prior to Python 2.5, if you had a try/except block that was expecting to catch something *other* than GeneratorExit or RuntimeError. So, the net effect would be an unintended hang, if we tried to support retrying until the generator can be closed. Regarding the GC second attempt, this behavior is actually exactly as-specified by the PEP's pseudo-code explanation of how close() is handled. A RuntimeError raised from close() does *not* close the generator; it specifically indicates that the generator has not in fact closed. At this point, after re-reading the PEP and looking at what the code is doing, it's clear that the behavior is "as specified", so the title of the bug is incorrect: the behavior is exactly as specified by PEP 342. So, the rest of my comments below are regarding whether PEP 342 should be changed. And really, the question there is whether it's sane to attempt heroic measures in order to run finally clauses in a generator whose code is *known* to be buggy. The RuntimeError basically says, "this generator is broken", and the GC also tries a second time to close it. If two close attempts don't close it, it's a dead duck. What other measures can we sanely add? We could try forcing the RuntimeError into the generator itself, but then we have to deal with the infinite loop possibility, and the oddities involved in getting to a language specification that can be implemented for Jython, IronPython, etc. On the whole, I think that we probably reached the right balance the first time around: a broken generator should not be allowed to handle the error of its own brokenness. -- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 21:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. -- Comme
[ python-Bugs-1495488 ] make altinstall installs pydoc
Bugs item #1495488, was opened at 2006-05-26 12:19
Message generated for change (Comment added) made by charlesmerriam
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&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: Tim Heaney (theaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: make altinstall installs pydoc
Initial Comment:
I did the "make altinstall" rather than the "make
install" as suggested on
http://www.python.org/download/releases/2.5/
This worked great, creating a
/usr/local/bin/python2.5
which doesn't clash with my /usr/bin/python. However,
it also created a
/usr/local/bin/pydoc
which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-22 23:50
Message:
Logged In: YES
user_id=1581732
Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc
would not have worked anyway. It's first line:
#!/usr/local/bin/python
would give an error because only /usr/local/bin/python2.5
exists.
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-22 00:14
Message:
Logged In: YES
user_id=827666
Sorry, I haven't had a chance to look at this again. I just
installed Python-2.5b1 and it's still the same way. Here's
what I did to fix things up after the make altinstall...
# cd /usr/local/bin
# for file in pydoc idle smtpd.py python-config; do
mv $file ${file}2.5
sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@'
${file}2.5
done
Now, how to fix up the Makefile.pre and setup.py so this
isn't necessary...
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-06 11:19
Message:
Logged In: YES
user_id=827666
I'm not sure I know how. It looks like the downloaded files
have the following shebang lines
Tools/scripts/pydoc => #!/usr/bin/env python
Tools/scripts/idle=> #! /usr/bin/env python
Lib/smtpd.py => #! /usr/bin/env python
Misc/python-config.in => [EMAIL PROTECTED]@/python
whereas the installed files have
/usr/local/bin/pydoc => #!/usr/local/bin/python
/usr/local/bin/idle => #!/usr/local/bin/python
/usr/local/bin/smtpd.py => #!/usr/local/bin/python
/usr/local/bin/python-config => #!/usr/local/bin/python
so they're already getting rewritten somewhere. We want both
their names and their shebang lines to have the version
/usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5
It seems that python-config appears in the Makefile, so
adding something like
sed -e "s,@BINDIR@,$(BINDIR)," <
$(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE)
$(INSTALL_SCRIPT) python-config
$(BINDIR)/python-config$(VERSION)$(EXE)
rm python-config
to Makefile.pre.in in an altlibainstall section or something
might be all we need for that.
The others are named in setup.py
# Scripts to install
scripts = ['Tools/scripts/pydoc',
'Tools/scripts/idle',
'Lib/smtpd.py']
but I haven't worked out where they get rewritten or
installed yet.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-04 20:02
Message:
Logged In: YES
user_id=21627
You are right: altinstall shouldn't overwrite these
conflicting files. For idle and pydoc, I would think that
altinstall should install version-specific copies - users
actually might want to run an idle or pydoc associated with
a specific version, likewise for python-config. I'm
uncertain why smtpd.py is installed at all.
Would you be willing to work on a patch? You are right that
the shebang line should get updated during the installation,
too.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archi
[ python-Bugs-1495488 ] make altinstall installs pydoc
Bugs item #1495488, was opened at 2006-05-26 12:19
Message generated for change (Comment added) made by theaney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&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: Tim Heaney (theaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: make altinstall installs pydoc
Initial Comment:
I did the "make altinstall" rather than the "make
install" as suggested on
http://www.python.org/download/releases/2.5/
This worked great, creating a
/usr/local/bin/python2.5
which doesn't clash with my /usr/bin/python. However,
it also created a
/usr/local/bin/pydoc
which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.
--
>Comment By: Tim Heaney (theaney)
Date: 2006-08-23 00:39
Message:
Logged In: YES
user_id=827666
Yeah, that's what the sed command is for.
By the way, it looks like python-config is taken care of in
release candidate 1. That is, after doing the altinstall for
2.5c1, I did
# for file in pydoc idle smtpd.py; do
mv $file ${file}2.5
sed -i
's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5
done
to fix things up.
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-22 23:50
Message:
Logged In: YES
user_id=1581732
Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc
would not have worked anyway. It's first line:
#!/usr/local/bin/python
would give an error because only /usr/local/bin/python2.5
exists.
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-22 00:14
Message:
Logged In: YES
user_id=827666
Sorry, I haven't had a chance to look at this again. I just
installed Python-2.5b1 and it's still the same way. Here's
what I did to fix things up after the make altinstall...
# cd /usr/local/bin
# for file in pydoc idle smtpd.py python-config; do
mv $file ${file}2.5
sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@'
${file}2.5
done
Now, how to fix up the Makefile.pre and setup.py so this
isn't necessary...
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-06 11:19
Message:
Logged In: YES
user_id=827666
I'm not sure I know how. It looks like the downloaded files
have the following shebang lines
Tools/scripts/pydoc => #!/usr/bin/env python
Tools/scripts/idle=> #! /usr/bin/env python
Lib/smtpd.py => #! /usr/bin/env python
Misc/python-config.in => [EMAIL PROTECTED]@/python
whereas the installed files have
/usr/local/bin/pydoc => #!/usr/local/bin/python
/usr/local/bin/idle => #!/usr/local/bin/python
/usr/local/bin/smtpd.py => #!/usr/local/bin/python
/usr/local/bin/python-config => #!/usr/local/bin/python
so they're already getting rewritten somewhere. We want both
their names and their shebang lines to have the version
/usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5
It seems that python-config appears in the Makefile, so
adding something like
sed -e "s,@BINDIR@,$(BINDIR)," <
$(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE)
$(INSTALL_SCRIPT) python-config
$(BINDIR)/python-config$(VERSION)$(EXE)
rm python-config
to Makefile.pre.in in an altlibainstall section or something
might be all we need for that.
The others are named in setup.py
# Scripts to install
scripts = ['Tools/scripts/pydoc',
'Tools/scripts/idle',
'Lib/smtpd.py']
but I haven't worked out where they get rewritten or
installed yet.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-04 20:02
Message:
Logged In: YES
user_id=21627
You are right: altinstall shouldn't overwrite these
conflicting files. For idle and pydoc, I would think that
altinstall should install version-specific copies - users
actually might want to run an idle or pydoc associated with
a specific version, likewise for python-config. I'm
un
[ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports
Bugs item #1531963, was opened at 2006-07-31 19:58
Message generated for change (Comment added) made by damonkohler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&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: None
Priority: 5
Submitted By: hakker.de (hakker_de)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketServer.TCPServer returns different ports
Initial Comment:
Providing 0 as a port in __init__ of
SocketServer.TCPServer leads to different values for
port in server_address and socket.getsockname().
Example:
import SocketServer
s = SocketServer.TCPServer(("0.0.0.0", 0), Handler)
s.server_address
-> ('0.0.0.0', 0)
s.socket.getsockname()
-> ('0.0.0.0', 39129)
s.server_address should also contain 39129 as the
port number for the free port found.
--
Comment By: Damon Kohler (damonkohler)
Date: 2006-08-23 01:36
Message:
Logged In: YES
user_id=705317
Patch 1545011 is a proposed fix.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
