From hifiber7@compuserve.com Mon Jan 3 05:03:14 2000 From: hifiber7@compuserve.com (hifiber7@compuserve.com) Date: Mon, 3 Jan 2000 00:03:14 -0500 (EST) Subject: [Python-bugs-list] AD:Family Reunion T Shirts & More (PR#168) Message-ID: <200001030503.AAA02677@python.org> Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We also can provide you with quality embroidery. We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Click reply to email us or call 1-800-810-4330 for more info Bill Kuppler Graphics From sjmachin@lexicon.net Mon Jan 3 09:55:51 2000 From: sjmachin@lexicon.net (sjmachin@lexicon.net) Date: Mon, 3 Jan 2000 04:55:51 -0500 (EST) Subject: [Python-bugs-list] Divide overflow (follow-on to bug #88) (PR#169) Message-ID: <200001030955.EAA06506@python.org> Full_Name: John Machin Version: 1.5.2 OS: Win NT w/s 4.0 Submission from: (NULL) (203.12.210.3) [sorry if this shouldn't be a new bug report but I couldn't nut out how to add on to the existing report] There is a dilemma here: BIGNEG / -1 should cause an overflow exception, not a crash. Pedantry would say that BIGNEG % -1 should *not* cause an exception, but return a result of zero. However / and % are computed by the same function, which doesn't know which answer the punter wants (could even be both). Practicality says that if someone's code executes BIGNEG % -1, they either know exactly what they're doing (checking to see what will happen), or they don't have a clue at all (it's not really a very meaningful computation, is it?), in which case throwing an exception is (IMO) acceptable --- I'm just suggesting that this be added to the documentation in the reference manual. From nick@cs.uchicago.edu Mon Jan 3 22:21:21 2000 From: nick@cs.uchicago.edu (nick@cs.uchicago.edu) Date: Mon, 3 Jan 2000 17:21:21 -0500 (EST) Subject: [Python-bugs-list] inconsistencies in rfc822.py (PR#170) Message-ID: <200001032221.RAA22663@python.org> Full_Name: Nick Russo Version: 1.5.2 (#10, Dec 30 1999, 12:07:33) OS: linux2 Submission from: seacow.cs.uchicago.edu (128.135.11.88) When I run the test program in rfc822.py on a mail file, ParsedDate shows the wrong day. parsedate_tz always returns 0 for weekday, Julian day, and DST flag. The documentation states that getdate "returns a time-compatible tuple, i.e. a tuple such as returned by time.localtime() or accepted by time.mktime()." If parsedate[_tz] and getdate[_tz] return tuples that are appropriate for time.mktime (and hence mktime_tz), perhaps the test program should use them that way. In addition, the documentation should note that getdate[_tz] and parsedate[_tz] return unhelpful values for fields 6,7, and 8 of their 9- or 10-tuples. *** rfc822-current.py Mon Jan 3 16:05:38 2000 --- rfc822-fix.py Mon Jan 3 16:15:59 2000 *************** *** 927,935 **** print 'Subject:', m.getheader('subject') print 'Date:', m.getheader('date') date = m.getdate_tz('date') if date: ! print 'ParsedDate:', time.asctime(date[:-1]), ! hhmmss = date[-1] hhmm, ss = divmod(hhmmss, 60) hh, mm = divmod(hhmm, 60) print "%+03d%02d" % (hh, mm), --- 927,937 ---- print 'Subject:', m.getheader('subject') print 'Date:', m.getheader('date') date = m.getdate_tz('date') + tz = date[-1] + date = time.localtime(mktime_tz(date)) if date: ! print 'ParsedDate:', time.asctime(date), ! hhmmss = tz hhmm, ss = divmod(hhmmss, 60) hh, mm = divmod(hhmm, 60) print "%+03d%02d" % (hh, mm), I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From tim_one@email.msn.com Mon Jan 3 23:46:16 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 3 Jan 2000 18:46:16 -0500 Subject: [Python-bugs-list] Divide overflow (follow-on to bug #88) (PR#169) In-Reply-To: <200001030955.EAA06506@python.org> Message-ID: <000b01bf5644$b9b56160$3fa0143f@tim> [John Machin] > ... > There is a dilemma here: BIGNEG / -1 should cause an overflow > exception, not a crash. Which it now does. > Pedantry would say that BIGNEG % -1 should *not* cause an > exception, but return a result of zero. The Lang Ref (section 5.6, Binary arithmetic operations) guarantees that x == (x/y)*y + (x%y) and divmod(x, y) == x/y, x%y for integer x and y, so if you can compute any one of {divmod(x,y), x/y, x%y} without exception, you have every right to insist all three be computable without exception, and to insist that the results satisfy these identities. So the *truly* pedantic answer is the one that's implemented. > ... I'm just suggesting that this be added to the documentation > in the reference manual. Just noting that the docs currently define no case of OverflowError, let alone this end case. From tim_one@email.msn.com Mon Jan 3 23:45:55 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Mon, 3 Jan 2000 18:45:55 -0500 (EST) Subject: [Python-bugs-list] Divide overflow (follow-on to bug #88) (PR#169) Message-ID: <200001032345.SAA24571@python.org> [John Machin] > ... > There is a dilemma here: BIGNEG / -1 should cause an overflow > exception, not a crash. Which it now does. > Pedantry would say that BIGNEG % -1 should *not* cause an > exception, but return a result of zero. The Lang Ref (section 5.6, Binary arithmetic operations) guarantees that x == (x/y)*y + (x%y) and divmod(x, y) == x/y, x%y for integer x and y, so if you can compute any one of {divmod(x,y), x/y, x%y} without exception, you have every right to insist all three be computable without exception, and to insist that the results satisfy these identities. So the *truly* pedantic answer is the one that's implemented. > ... I'm just suggesting that this be added to the documentation > in the reference manual. Just noting that the docs currently define no case of OverflowError, let alone this end case. From sjmachin@lexicon.net Thu Jan 6 12:53:55 2000 From: sjmachin@lexicon.net (sjmachin@lexicon.net) Date: Thu, 6 Jan 2000 07:53:55 -0500 (EST) Subject: [Python-bugs-list] Divide overflow (follow-on to bug #88) (PR#169) Message-ID: <200001061253.HAA13335@python.org> The Tim emitted: > [John Machin] > > Pedantry would say that BIGNEG % -1 should *not* cause an > > exception, but return a result of zero. > > The Lang Ref (section 5.6, Binary arithmetic operations) guarantees that > > x == (x/y)*y + (x%y) > and > divmod(x, y) == x/y, x%y > > for integer x and y, so if you can compute any one of {divmod(x,y), x/y, > x%y} without exception, you have every right to insist all three be > computable without exception, and to insist that the results satisfy > these identities. So the *truly* pedantic answer is the one > that's implemented. It says the integer division and modulo operators are connected by the identity x == (x/y)*y + (x%y) etc etc. I don't see how you can construe that as a guarantee, nor how you infer the right to insist that all three be computable if one is. However O great Tim I'll leave the field to you as the archdefiner of pedantry ;-) > > > ... I'm just suggesting that this be added to the documentation > > in the reference manual. > > Just noting that the docs currently define no case of OverflowError, let > alone this end case. *snort* see Lang Ref section 3.2: Plain integers These represent numbers in the range -2147483648 through 2147483647. (The range may be larger on machines with a larger natural word size, but not smaller.) When the result of an operation falls outside this range, the exception OverflowError is raised. For the purpose of shift and mask operations, integers are assumed to have a binary, 2's complement notation using 32 or more bits, and hiding no bits from the user (i.e., all 4294967296 different bit patterns correspond to different values). To recap: On systems where the supported range does not include -BIGNEG: [i.e all systems unless the Tim has ported Python to a ones-complement machine in his attic] BIGNEG / (-1) must raise OverflowError. divmod(BIGNEG, -1) must raise OverflowError because it cannot return a correct value for the "div" part. We need to decide whether BIGNEG % (-1) should return the correct result (zero) or raise OverflowError or do whichever an implementor decides is most convenient, and document the decision. I vote for OverflowError, on pragmatic grounds. Lapsing back ever so slightly into pedantry, I'd suggest also changing the doco to say "would fall outside" instead of "falls outside". Cheers, John From Bruce.Sherwood@cmu.edu Fri Jan 7 16:08:18 2000 From: Bruce.Sherwood@cmu.edu (Bruce.Sherwood@cmu.edu) Date: Fri, 7 Jan 2000 11:08:18 -0500 (EST) Subject: [Python-bugs-list] Tk create_arc bug on Mac (PR#171) Message-ID: <200001071608.LAA04316@python.org> Full_Name: Bruce Sherwood Version: 1.5.2c1 OS: Mac 8.1 Submission from: hejmo.rem.cmu.edu (128.2.83.199) I'm new to Python, so maybe this bug is known, but I couldn't find any reference to it in the bug machinery or the newsgroups. On the Mac invoking Tkinter create_arc with start=0.0, extent=360.0 does not draw an ellipse but rather draws only a line at 3 o'clock. Changing to extent = 359.0 draws a (nearly) complete ellipse, but of course with extra lines near 3 o'clock. From Bruce.Sherwood@cmu.edu Fri Jan 7 16:21:25 2000 From: Bruce.Sherwood@cmu.edu (Bruce.Sherwood@cmu.edu) Date: Fri, 7 Jan 2000 11:21:25 -0500 (EST) Subject: [Python-bugs-list] Reproducible crash of Mac IDE (PR#172) Message-ID: <200001071621.LAA04783@python.org> Full_Name: Bruce Sherwood Version: 1.5.2c1 OS: Mac 8.1 Submission from: hejmo.rem.cmu.edu (128.2.83.199) I'm writing tiny programs invoking Tkinter, to learn how to use it. If I open my script from the Mac IDE and click "Run all" in the script title bar, the script runs okay, but when I try to quit running, the entire IDE locks up. I have to do an unpleasant Mac "Force quit" to get out. This is completely reproducible with tiny programs containing "from Tkinter import *". I've had to resort to the awkward strategem of saving the script, then dragging the script file onto the Python interpreter. In that case I can quit normally. It means that I'm only using the IDE as a (structured) text editor. I don't have the quit problem in Mac IDE with scripts that don't invoke Tkinter. From jeffallen@sourcenet.org Sun Jan 9 22:22:21 2000 From: jeffallen@sourcenet.org (jeffallen@sourcenet.org) Date: Sun, 9 Jan 2000 17:22:21 -0500 (EST) Subject: [Python-bugs-list] Good Luck in the New Millenium (PR#173) Message-ID: <200001092222.RAA23614@python.org> To be removed from this mailing list immediately press reply and enter REMOVE on the subject line. Would you like to be able to buy Computers and Software at wholesale? At below what the stores Pay? Reply with "MORE INFO" in the subject field If you are a reseller and would like information on paying what the distributors pay then Reply with Reseller in the subject field. If you have computer products you need to sell then email your details From dennis.mccoy@mindspring.com Sun Jan 9 22:58:04 2000 From: dennis.mccoy@mindspring.com (dennis.mccoy@mindspring.com) Date: Sun, 9 Jan 2000 17:58:04 -0500 (EST) Subject: [Python-bugs-list] dir function anomoly (PR#174) Message-ID: <200001092258.RAA24534@python.org> Full_Name: Dennis McCoy Version: 1.5.2 OS: Win 95 Submission from: user-33qsde3.dialup.mindspring.com (199.174.53.195) Coded and saved a module with the following content # div.py def remainder(a,b): q = a/b r = a - q*b return r def divide(a,b): q = a/b r = a - q*b return (q,r) Wrote a script that imports all the functions in div.py # bug2.py from div import * # Import all the functions in the module div.py x = dir() # Get all the namespace entries except for the print x # and print them x = dir(div) # x is supposed to get the contents of module div print x The first call for dir() works as expected and reports both of the functions in the imported file div.py The second call for dir(div) generates the following Python error: NameError: div From tim_one@email.msn.com Mon Jan 10 01:07:44 2000 From: tim_one@email.msn.com (Tim Peters) Date: Sun, 9 Jan 2000 20:07:44 -0500 Subject: [Python-bugs-list] dir function anomoly (PR#174) In-Reply-To: <200001092258.RAA24534@python.org> Message-ID: <000101bf5b07$1a3f06a0$842d153f@tim> [Dennis McCoy] [removing comments cuz mailer is breaking the lines in horrid places] > # div.py > def remainder(a,b): > q = a/b > r = a - q*b > return r > > def divide(a,b): > q = a/b > r = a - q*b > return (q,r) > > Wrote a script that imports all the functions in div.py > > # bug2.py > > from div import * > > x = dir() > print x > > x = dir(div) > print x > > The first call for dir() works as expected and reports both of > the functions in the imported file div.py > > The second call for dir(div) generates the following Python > error: > NameError: div Dennis, sorry, but this isn't a bug! It's behaving as designed and as documented. "from div import *" does not import div, which is why you get a later NameError on div. If you want the name div to be visible, you need to do "import div". "from xxx import yyy, zzz" never binds xxx, only yyy and zzz. For more info, review the docs. Note that it's *generally* a bad idea to use the "import *" form at all (that's meant as a convenience for interactive mode, and for modules like Tkinter that export very broad interfaces with unlikely-to-conflict names). From tim_one@email.msn.com Mon Jan 10 01:07:51 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Sun, 9 Jan 2000 20:07:51 -0500 (EST) Subject: [Python-bugs-list] dir function anomoly (PR#174) Message-ID: <200001100107.UAA27629@python.org> [Dennis McCoy] [removing comments cuz mailer is breaking the lines in horrid places] > # div.py > def remainder(a,b): > q = a/b > r = a - q*b > return r > > def divide(a,b): > q = a/b > r = a - q*b > return (q,r) > > Wrote a script that imports all the functions in div.py > > # bug2.py > > from div import * > > x = dir() > print x > > x = dir(div) > print x > > The first call for dir() works as expected and reports both of > the functions in the imported file div.py > > The second call for dir(div) generates the following Python > error: > NameError: div Dennis, sorry, but this isn't a bug! It's behaving as designed and as documented. "from div import *" does not import div, which is why you get a later NameError on div. If you want the name div to be visible, you need to do "import div". "from xxx import yyy, zzz" never binds xxx, only yyy and zzz. For more info, review the docs. Note that it's *generally* a bad idea to use the "import *" form at all (that's meant as a convenience for interactive mode, and for modules like Tkinter that export very broad interfaces with unlikely-to-conflict names). From vadimch@yahoo.com Mon Jan 10 03:01:32 2000 From: vadimch@yahoo.com (vadimch@yahoo.com) Date: Sun, 9 Jan 2000 22:01:32 -0500 (EST) Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) Message-ID: <200001100301.WAA00066@python.org> Full_Name: Vadim Chugunov Version: 1.5.2 OS: NT Submission from: evrtwa1-ar3-233-065.dsl.gtei.net (4.3.233.65) Consider this code: x = 1 exec "x=x+1" print x The result is 2. On the other hand, def f(): x=x+1 exec f.func_code results in NameError: x Exec on files is broken as well. As far as I can see, the problem is that: a) PyFrame_New() ignores the locals passed in if the code object has the CO_NEWLOCALS flag set. b) exec_statement() does not call PyFrame_LocalsToFast() unless a string is being executed. Here's what I think the fix should be: =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/frameobject.c,v retrieving revision 2.36 diff -c -r2.36 frameobject.c *** frameobject.c 1998/10/19 14:20:20 2.36 --- frameobject.c 2000/01/09 12:14:27 *************** *** 219,239 **** f->f_code = code; Py_INCREF(globals); f->f_globals = globals; ! if (code->co_flags & CO_NEWLOCALS) { ! if (code->co_flags & CO_OPTIMIZED) ! locals = NULL; /* Let fast_2_locals handle it */ ! else { ! locals = PyDict_New(); ! if (locals == NULL) { ! Py_DECREF(f); ! return NULL; ! } ! } } else { ! if (locals == NULL) locals = globals; ! Py_INCREF(locals); } f->f_locals = locals; f->f_trace = NULL; --- 219,243 ---- f->f_code = code; Py_INCREF(globals); f->f_globals = globals; ! if (locals!=NULL) { ! Py_INCREF(locals); } else { ! if (code->co_flags & CO_NEWLOCALS) { ! if (code->co_flags & CO_OPTIMIZED) ! locals = NULL; /* Let fast_2_locals handle it */ ! else { ! locals = PyDict_New(); ! if (locals == NULL) { ! Py_DECREF(f); ! return NULL; ! } ! } ! } ! else { locals = globals; ! Py_INCREF(locals); ! } } f->f_locals = locals; f->f_trace = NULL; *************** *** 251,256 **** --- 255,263 ---- f->f_localsplus[extras] = NULL; f->f_valuestack = f->f_localsplus + f->f_nlocals; + + if (f->f_locals != NULL) + PyFrame_LocalsToFast(f,0); return f; } =================================================================== RCS file: /projects/cvsroot/python/dist/src/Python/ceval.c,v retrieving revision 2.165 diff -c -r2.165 ceval.c *** ceval.c 1999/11/15 19:29:33 2.165 --- ceval.c 2000/01/10 02:47:25 *************** *** 2782,2787 **** --- 2782,2789 ---- if (v == NULL) return -1; Py_DECREF(v); + if (plain) + PyFrame_LocalsToFast(f, 0); return 0; } if (PyFile_Check(prog)) { *************** *** 2790,2795 **** --- 2792,2799 ---- if (PyRun_File(fp, name, Py_file_input, globals, locals) == NULL) return -1; + if (plain) + PyFrame_LocalsToFast(f, 0); return 0; } s = PyString_AsString(prog); =================================================================== I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From vadimch@yahoo.com Mon Jan 10 03:01:54 2000 From: vadimch@yahoo.com (vadimch@yahoo.com) Date: Sun, 9 Jan 2000 22:01:54 -0500 (EST) Subject: [Python-bugs-list] Exec statement inconsistency (PR#176) Message-ID: <200001100301.WAA00089@python.org> Full_Name: Vadim Chugunov Version: 1.5.2 OS: NT Submission from: evrtwa1-ar3-233-065.dsl.gtei.net (4.3.233.65) Consider this code: x = 1 exec "x=x+1" print x The result is 2. On the other hand, def f(): x=x+1 exec f.func_code results in NameError: x Exec on files is broken as well. As far as I can see, the problem is that: a) PyFrame_New() ignores the locals passed in if the code object has the CO_NEWLOCALS flag set. b) exec_statement() does not call PyFrame_LocalsToFast() unless a string is being executed. Here's what I think the fix should be: =================================================================== RCS file: /projects/cvsroot/python/dist/src/Objects/frameobject.c,v retrieving revision 2.36 diff -c -r2.36 frameobject.c *** frameobject.c 1998/10/19 14:20:20 2.36 --- frameobject.c 2000/01/09 12:14:27 *************** *** 219,239 **** f->f_code = code; Py_INCREF(globals); f->f_globals = globals; ! if (code->co_flags & CO_NEWLOCALS) { ! if (code->co_flags & CO_OPTIMIZED) ! locals = NULL; /* Let fast_2_locals handle it */ ! else { ! locals = PyDict_New(); ! if (locals == NULL) { ! Py_DECREF(f); ! return NULL; ! } ! } } else { ! if (locals == NULL) locals = globals; ! Py_INCREF(locals); } f->f_locals = locals; f->f_trace = NULL; --- 219,243 ---- f->f_code = code; Py_INCREF(globals); f->f_globals = globals; ! if (locals!=NULL) { ! Py_INCREF(locals); } else { ! if (code->co_flags & CO_NEWLOCALS) { ! if (code->co_flags & CO_OPTIMIZED) ! locals = NULL; /* Let fast_2_locals handle it */ ! else { ! locals = PyDict_New(); ! if (locals == NULL) { ! Py_DECREF(f); ! return NULL; ! } ! } ! } ! else { locals = globals; ! Py_INCREF(locals); ! } } f->f_locals = locals; f->f_trace = NULL; *************** *** 251,256 **** --- 255,263 ---- f->f_localsplus[extras] = NULL; f->f_valuestack = f->f_localsplus + f->f_nlocals; + + if (f->f_locals != NULL) + PyFrame_LocalsToFast(f,0); return f; } =================================================================== RCS file: /projects/cvsroot/python/dist/src/Python/ceval.c,v retrieving revision 2.165 diff -c -r2.165 ceval.c *** ceval.c 1999/11/15 19:29:33 2.165 --- ceval.c 2000/01/10 02:47:25 *************** *** 2782,2787 **** --- 2782,2789 ---- if (v == NULL) return -1; Py_DECREF(v); + if (plain) + PyFrame_LocalsToFast(f, 0); return 0; } if (PyFile_Check(prog)) { *************** *** 2790,2795 **** --- 2792,2799 ---- if (PyRun_File(fp, name, Py_file_input, globals, locals) == NULL) return -1; + if (plain) + PyFrame_LocalsToFast(f, 0); return 0; } s = PyString_AsString(prog); =================================================================== I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From tim_one@email.msn.com Mon Jan 10 07:36:33 2000 From: tim_one@email.msn.com (Tim Peters) Date: Mon, 10 Jan 2000 02:36:33 -0500 Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) In-Reply-To: <200001100301.WAA00066@python.org> Message-ID: <000501bf5b3d$6bf03420$532d153f@tim> [Vadim Chugunov] > Consider this code: > x = 1 > exec "x=x+1" > print x > The result is 2. On the other hand, > def f(): > x=x+1 > exec f.func_code > results in NameError: x > Exec on files is broken as well. Vadim, I think Guido's out of town for a while. This is a delicate area of the interpreter and I doubt he'll be willing to make fundamental changes in what it does. For starters, the NameError above has nothing to do with exec. You get the same error if you call f() directly (in the current CVS version of Python, it raises the more descriptive UnboundLocalError instead). This is by design: "the rules" say that x is a local name in f(), and the code attempts to reference its value before x has been bound. If you change f to def f(): global x x = x+1 then it works as you hope whether called directly or via exec. BTW, if it wasn't clear, you don't get the error when you run the code at module level because the locals and globals are the same namespace there. > As far as I can see, the problem is that: > a) PyFrame_New() ignores the locals passed in if the > code object has the CO_NEWLOCALS flag set. > > b) exec_statement() does not call PyFrame_LocalsToFast() unless > a string is being executed. It's been a long time since I thought I understood all the rules here -- there are subtleties. Still, it looks odd to me too that e.g. def f(): x = 1 exec "x=x+1" print x # prints 2 def g(): x = 1 exec compile("x=x+1", "", "exec") print x # prints 1 f() g() I'll leave that one for Guido to rationalize away ! From tim_one@email.msn.com Mon Jan 10 07:36:16 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Mon, 10 Jan 2000 02:36:16 -0500 (EST) Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) Message-ID: <200001100736.CAA10773@python.org> [Vadim Chugunov] > Consider this code: > x = 1 > exec "x=x+1" > print x > The result is 2. On the other hand, > def f(): > x=x+1 > exec f.func_code > results in NameError: x > Exec on files is broken as well. Vadim, I think Guido's out of town for a while. This is a delicate area of the interpreter and I doubt he'll be willing to make fundamental changes in what it does. For starters, the NameError above has nothing to do with exec. You get the same error if you call f() directly (in the current CVS version of Python, it raises the more descriptive UnboundLocalError instead). This is by design: "the rules" say that x is a local name in f(), and the code attempts to reference its value before x has been bound. If you change f to def f(): global x x = x+1 then it works as you hope whether called directly or via exec. BTW, if it wasn't clear, you don't get the error when you run the code at module level because the locals and globals are the same namespace there. > As far as I can see, the problem is that: > a) PyFrame_New() ignores the locals passed in if the > code object has the CO_NEWLOCALS flag set. > > b) exec_statement() does not call PyFrame_LocalsToFast() unless > a string is being executed. It's been a long time since I thought I understood all the rules here -- there are subtleties. Still, it looks odd to me too that e.g. def f(): x = 1 exec "x=x+1" print x # prints 2 def g(): x = 1 exec compile("x=x+1", "", "exec") print x # prints 1 f() g() I'll leave that one for Guido to rationalize away ! From simonb@logical.co.za Tue Jan 11 10:17:41 2000 From: simonb@logical.co.za (simonb@logical.co.za) Date: Tue, 11 Jan 2000 05:17:41 -0500 (EST) Subject: [Python-bugs-list] Syntax (PR#177) Message-ID: <200001111017.FAA14158@python.org> Full_Name: Simon Barratt Version: 1-5-2 OS: NT 4.0 Submission from: (NULL) (196.30.164.5) Hi there I don't know if this is a bug, or is intentional behaviour for a specific reason. The following code produces a syntax error about the continue not being within a looping structure rather than a prefectly silly infinite loop... while 1: try: continue except: pass where the following works as one would expect... while 1: try: raise 1 except: continue I figure that there is more likely a sane reason for this behaviour than being a bug, but I am curious. Thanks Simon From fdrake@acm.org Tue Jan 11 14:45:03 2000 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 11 Jan 2000 09:45:03 -0500 (EST) Subject: [Python-bugs-list] Divide overflow (follow-on to bug #88) (PR#169) In-Reply-To: <200001061253.HAA13335@python.org> References: <200001061253.HAA13335@python.org> Message-ID: <14459.16879.318869.379558@weyr.cnri.reston.va.us> sjmachin@lexicon.net writes: > Lapsing back ever so slightly into pedantry, I'd suggest also changing > the doco to say "would fall outside" instead of "falls outside". Lapse noted. ;) I've made the change in the documentation sources; it will be reflected in the next documentation release. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Tue Jan 11 14:44:05 2000 From: fdrake@acm.org (fdrake@acm.org) Date: Tue, 11 Jan 2000 09:44:05 -0500 (EST) Subject: [Python-bugs-list] Divide overflow (follow-on to bug #88) (PR#169) Message-ID: <200001111444.JAA19357@python.org> sjmachin@lexicon.net writes: > Lapsing back ever so slightly into pedantry, I'd suggest also changing > the doco to say "would fall outside" instead of "falls outside". Lapse noted. ;) I've made the change in the documentation sources; it will be reflected in the next documentation release. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From tim_one@email.msn.com Tue Jan 11 17:10:17 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 11 Jan 2000 12:10:17 -0500 Subject: [Python-bugs-list] Syntax (PR#177) In-Reply-To: <200001111017.FAA14158@python.org> Message-ID: <000001bf5c56$bc320200$4da0143f@tim> [Simon Barratt, putting "continue" in a "try" block] > I don't know if this is a bug, or is intentional behaviour > for a specific reason. Actually, it's a bit of both . See the Language Reference Manual's section on the "continue" statement, particularly the footnote: The restriction on occurring in the try clause is implementer's laziness and will eventually be lifted. It's been this way (and documented) forever; it's simply hard to implement given the current structure of the interpreter loop. Rest assured there's nothing *conceptually* wrong with putting continue in a try! It's simply an implementation restriction; the error msg should probably make that clearer. IIRC, JPython doesn't have this restriction. "Someday" it will get repaired in CPython too. From tim_one@email.msn.com Tue Jan 11 17:09:59 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 11 Jan 2000 12:09:59 -0500 (EST) Subject: [Python-bugs-list] Syntax (PR#177) Message-ID: <200001111709.MAA22856@python.org> [Simon Barratt, putting "continue" in a "try" block] > I don't know if this is a bug, or is intentional behaviour > for a specific reason. Actually, it's a bit of both . See the Language Reference Manual's section on the "continue" statement, particularly the footnote: The restriction on occurring in the try clause is implementer's laziness and will eventually be lifted. It's been this way (and documented) forever; it's simply hard to implement given the current structure of the interpreter loop. Rest assured there's nothing *conceptually* wrong with putting continue in a try! It's simply an implementation restriction; the error msg should probably make that clearer. IIRC, JPython doesn't have this restriction. "Someday" it will get repaired in CPython too. From skip@mojam.com (Skip Montanaro) Tue Jan 11 17:34:26 2000 From: skip@mojam.com (Skip Montanaro) (Skip Montanaro) Date: Tue, 11 Jan 2000 11:34:26 -0600 (CST) Subject: [Python-bugs-list] Syntax (PR#177) In-Reply-To: <200001111017.FAA14158@python.org> References: <200001111017.FAA14158@python.org> Message-ID: <14459.27042.507623.680973@beluga.mojam.com> Simon> I don't know if this is a bug, or is intentional behaviour for a Simon> specific reason. Simon> The following code produces a syntax error about the continue not Simon> being within a looping structure rather than a prefectly silly Simon> infinite loop... Simon> while 1: Simon> try: Simon> continue Simon> except: Simon> pass Continue, break and return within try clauses are not allowed. It's a known limitation of the implementation. The language reference manual states: A continue statement is illegal in the try clause. (The reason is a problem with the current implementation -- this restriction may be lifted in the future). Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/ 847-971-7098 From seanj@speakeasy.org Wed Jan 12 02:34:53 2000 From: seanj@speakeasy.org (seanj@speakeasy.org) Date: Tue, 11 Jan 2000 21:34:53 -0500 (EST) Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamically resizing list (PR#178) Message-ID: <200001120234.VAA06167@python.org> Full_Name: Sean Jensen-Grey Version: 1.5.2 OS: W2k Submission from: tide87.microsoft.com (131.107.3.87) l_sync = [ '# comment', '#this is a comment', '#define foo bar' ] print l_sync print for x in l_sync: print x print for x in l_sync: if x[0] == '#': print x if x[0:2] != '#d': l_sync.remove(x) print print l_sync # the desired output should be #define foo bar # what is happening **I think** is that # iterator i is set to 0 # l_sync[0] is deleted, array shifts to the left by one # iterator i is incremented by 1 # l_sync[1] now referes to #define, skipping over #this is a comment # the iterator merrily marches along as the array is dynamically resized # if you change the #l_sync = [ '# comment', '#this is a comment', '#define foo bar' ] #l_sync = [ '# comment', 'foo','#this is a comment', '#define foo bar' ] # you will see what I mean... # is this expected behavior? From tim_one@email.msn.com Wed Jan 12 04:31:42 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 11 Jan 2000 23:31:42 -0500 Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamically resizing list (PR#178) In-Reply-To: <200001120234.VAA06167@python.org> Message-ID: <000801bf5cb5$ed958ba0$da2d153f@tim> [Sean Jensen-Grey, mutating a list while iterating over it] > ... > # is this expected behavior? Yes indeed. See the Language Reference Manual, section "The 'for' statement". Change, e.g., for x in l_sync: to for x in l_sync[:]: if that's not the behavior you want. From tim_one@email.msn.com Wed Jan 12 04:31:10 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 11 Jan 2000 23:31:10 -0500 (EST) Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamically resizing list (PR#178) Message-ID: <200001120431.XAA12875@python.org> [Sean Jensen-Grey, mutating a list while iterating over it] > ... > # is this expected behavior? Yes indeed. See the Language Reference Manual, section "The 'for' statement". Change, e.g., for x in l_sync: to for x in l_sync[:]: if that's not the behavior you want. From seanj@speakeasy.org Wed Jan 12 05:19:56 2000 From: seanj@speakeasy.org (Sean Jensen-Grey) Date: Tue, 11 Jan 2000 21:19:56 -0800 (PST) Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamically resizing list (PR#178) In-Reply-To: <000801bf5cb5$ed958ba0$da2d153f@tim> Message-ID: Yes, that is the behaviour I was looking for. Thank You. I guess the bug can be resolved RTFM. But it should still work the way I want it! B^) I achieved the same result with the code below, after accounting for the array compaction. Is the temporary copy l_sync[:] as expensive as a deepcopy? i = 0; while (i != len(l_sync)): x = l_sync[0] if x[0] == '#': print(x) if x[0:2] != '#d': del l_sync[i] else: i = i + 1 On Tue, 11 Jan 2000, Tim Peters wrote: > [Sean Jensen-Grey, mutating a list while iterating over it] > > ... > > # is this expected behavior? > > Yes indeed. See the Language Reference Manual, section "The 'for' > statement". > > Change, e.g., > > for x in l_sync: > > to > > for x in l_sync[:]: > > if that's not the behavior you want. > > From seanj@speakeasy.org Wed Jan 12 05:18:55 2000 From: seanj@speakeasy.org (seanj@speakeasy.org) Date: Wed, 12 Jan 2000 00:18:55 -0500 (EST) Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamically (PR#179) Message-ID: <200001120518.AAA17237@python.org> Yes, that is the behaviour I was looking for. Thank You. I guess the bug can be resolved RTFM. But it should still work the way I want it! B^) I achieved the same result with the code below, after accounting for the array compaction. Is the temporary copy l_sync[:] as expensive as a deepcopy? i = 0; while (i != len(l_sync)): x = l_sync[0] if x[0] == '#': print(x) if x[0:2] != '#d': del l_sync[i] else: i = i + 1 On Tue, 11 Jan 2000, Tim Peters wrote: > [Sean Jensen-Grey, mutating a list while iterating over it] > > ... > > # is this expected behavior? > > Yes indeed. See the Language Reference Manual, section "The 'for' > statement". > > Change, e.g., > > for x in l_sync: > > to > > for x in l_sync[:]: > > if that's not the behavior you want. > > From tim_one@email.msn.com Wed Jan 12 05:42:43 2000 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 12 Jan 2000 00:42:43 -0500 Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamicallyresizing list (PR#178) In-Reply-To: Message-ID: <000901bf5cbf$d905ad00$da2d153f@tim> [Sean Jensen-Grey] > Yes, that is the behaviour I was looking for. Thank You. I > guess the bug can be resolved RTFM. But it should still > work the way I want it! B^) Well, I'm not Guido, but this won't change -- it would break far too much code; e.g., I routinely do breadth-first traversal of directed graphs via # return list of nodes reachable from root, in breadth-first # order def bfirst(root): all = [root] seen = {root: 1} for x in all: for kid in x.children(): if not seen.has_key(kid): seen[kid] = 1 all.append(kid) return all That is, "all" grows *during* the loop, and x picks up each one added in queue order. Sick, but pretty . > I achieved the same result with the code below, after > accounting for the array compaction. Sick, but strained . If you don't want to copy, how about iterating over l_sync backwards? for i in range(len(l_sync)-1, -1, -1): if l_sync[i].isevil(): del l_sync[i] This works because only elements whose indices have *already* been examined can get deleted; it's also enormously more efficient if most of the elements get deleted (deleting from the end of a list is much cheaper than deleting from its front). Sick, but effective . > Is the temporary copy l_sync[:] as expensive as a deepcopy? It's a shallow copy; under the covers it (just) copies len(l_sync) pointers; l_sync[:][i] is l_sync[i] is true for all i in range(len(l_sync)). From tim_one@email.msn.com Wed Jan 12 05:42:11 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Wed, 12 Jan 2000 00:42:11 -0500 (EST) Subject: [Python-bugs-list] Iterator doesn't re-evaluate with a dynamicallyresizing list (PR#178) Message-ID: <200001120542.AAA20104@python.org> [Sean Jensen-Grey] > Yes, that is the behaviour I was looking for. Thank You. I > guess the bug can be resolved RTFM. But it should still > work the way I want it! B^) Well, I'm not Guido, but this won't change -- it would break far too much code; e.g., I routinely do breadth-first traversal of directed graphs via # return list of nodes reachable from root, in breadth-first # order def bfirst(root): all = [root] seen = {root: 1} for x in all: for kid in x.children(): if not seen.has_key(kid): seen[kid] = 1 all.append(kid) return all That is, "all" grows *during* the loop, and x picks up each one added in queue order. Sick, but pretty . > I achieved the same result with the code below, after > accounting for the array compaction. Sick, but strained . If you don't want to copy, how about iterating over l_sync backwards? for i in range(len(l_sync)-1, -1, -1): if l_sync[i].isevil(): del l_sync[i] This works because only elements whose indices have *already* been examined can get deleted; it's also enormously more efficient if most of the elements get deleted (deleting from the end of a list is much cheaper than deleting from its front). Sick, but effective . > Is the temporary copy l_sync[:] as expensive as a deepcopy? It's a shallow copy; under the covers it (just) copies len(l_sync) pointers; l_sync[:][i] is l_sync[i] is true for all i in range(len(l_sync)). From Ryosuke.Nakao@cssi.co.jp Wed Jan 12 12:37:15 2000 From: Ryosuke.Nakao@cssi.co.jp (Ryosuke.Nakao@cssi.co.jp) Date: Wed, 12 Jan 2000 07:37:15 -0500 (EST) Subject: [Python-bugs-list] popen2(make test) (PR#180) Message-ID: <200001121237.HAA28440@python.org> Full_Name: Ryosuke Nakao Version: 1.5.2 OS: Solaris7 Submission from: (NULL) (157.77.16.21) When doing make test on the latest(as of 12 Jan 2000) python version, the popen2 tests fails. output from test_open2: testing popen2... testing popen3... Traceback (innermost last): File "Lib/test/test_popen2.py", line 16, in ? main() File "Lib/test/test_popen2.py", line 14, in main popen2._test() File "./Lib/popen2.py", line 95, in _test assert not _active AssertionError From cha@tandberg.no Wed Jan 12 14:49:31 2000 From: cha@tandberg.no (cha@tandberg.no) Date: Wed, 12 Jan 2000 09:49:31 -0500 (EST) Subject: [Python-bugs-list] Telnet close (PR#181) Message-ID: <200001121449.JAA00336@python.org> Full_Name: Carl Henrik Aaby Version: 1.5.2 OS: Windows NT4.0 Submission from: (NULL) (195.139.43.1) The telnet.close() object does not close the telnet session. Session will only be closed after a timeout on the remote side. From akuchlin@mems-exchange.org Wed Jan 12 22:12:25 2000 From: akuchlin@mems-exchange.org (akuchlin@mems-exchange.org) Date: Wed, 12 Jan 2000 17:12:25 -0500 (EST) Subject: [Python-bugs-list] TCP_NODELAY not found in socketmodule (PR#182) Message-ID: <200001122212.RAA10019@python.org> Full_Name: A.M. Kuchling Version: CVS version OS: Solaris 2.6 Submission from: amarok.cnri.reston.va.us (132.151.7.26) I wanted to use the TCP_NODELAY socket option, but it wasn't found in the socket module, even though socketmodule.c contains: #ifdef TCP_NODELAY insint(d, "TCP_NODELAY", TCP_NODELAY); #endif "man tcp" on Solaris says that TCP_NODELAY is defined in netinet/tcp.h, and the Open Groups Unix98 spec agrees (http://www.opengroup.org/onlinepubs/009619199/ninettcp.htm). socketmodule.c doesn't include that header file. Fix: #include in socketmodule.c. But are there Unix platforms which don't have that header, and will break? (Perhaps the configure script could check for it.) From guido@CNRI.Reston.VA.US Wed Jan 12 22:39:24 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 12 Jan 2000 17:39:24 -0500 (EST) Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) Message-ID: <200001122239.RAA10631@python.org> > It's been a long time since I thought I understood all the rules here -- > there are subtleties. Still, it looks odd to me too that e.g. > > def f(): > x = 1 > exec "x=x+1" > print x # prints 2 > > def g(): > x = 1 > exec compile("x=x+1", "", "exec") > print x # prints 1 > > f() > g() > > I'll leave that one for Guido to rationalize away ! *That* one's a bug -- the exec statement is supposed to sync back the locals fron the dict to their fast form, but the code to do that is only present when the argument is a string. I'm fixing this as we speak. --Guido van Rossum (home page: http://www.python.org/~guido/) From just@letterror.com Thu Jan 13 00:29:54 2000 From: just@letterror.com (just@letterror.com) Date: Wed, 12 Jan 2000 19:29:54 -0500 (EST) Subject: [Python-bugs-list] Re: Reproducible crash of Mac IDE (PR#172) Message-ID: <200001130029.TAA14980@python.org> At 6:28 PM -0500 12-01-2000, Guido van Rossum wrote: >> Full_Name: Bruce Sherwood >> Version: 1.5.2c1 >> OS: Mac 8.1 >> Submission from: hejmo.rem.cmu.edu (128.2.83.199) >> >> >> I'm writing tiny programs invoking Tkinter, to learn how to use it. If I >>open >my >> script from the Mac IDE and click "Run all" in the script title bar, the >script >> runs okay, but when I try to quit running, the entire IDE locks up. I >>have to >do >> an unpleasant Mac "Force quit" to get out. This is completely reproducible >with >> tiny programs containing "from Tkinter import *". >> >> I've had to resort to the awkward strategem of saving the script, then >dragging >> the script file onto the Python interpreter. In that case I can quit >normally. >> It means that I'm only using the IDE as a (structured) text editor. >> >> I don't have the quit problem in Mac IDE with scripts that don't invoke >> Tkinter. I'm sorry to inform you that the Mac Python IDE is not compatible with Tkinter. At all. Conflicting event loops and all. Sorry! Just From bas@andrew.cmu.edu Thu Jan 13 04:47:09 2000 From: bas@andrew.cmu.edu (bas@andrew.cmu.edu) Date: Wed, 12 Jan 2000 23:47:09 -0500 (EST) Subject: [Python-bugs-list] Re: Reproducible crash of Mac IDE (PR#172) Message-ID: <200001130447.XAA22089@python.org> --On Thu, Jan 13, 2000 01:30 +0100 Just van Rossum wrote: > I'm sorry to inform you that the Mac Python IDE is not compatible with > Tkinter. At all. Conflicting event loops and all. Thanks for the confirmation. At least now I won't keep suspecting it's me the novice at fault! Bruce Sherwood From bas@andrew.cmu.edu Thu Jan 13 06:00:02 2000 From: bas@andrew.cmu.edu (bas@andrew.cmu.edu) Date: Thu, 13 Jan 2000 01:00:02 -0500 (EST) Subject: [Python-bugs-list] Re: Reproducible crash of Mac IDE (PR#172) Message-ID: <200001130600.BAA22869@python.org> --On Wed, Jan 12, 2000 18:28 -0500 Guido van Rossum wrote: > Bruce, > > Are you using the default Python IDE or the separate (much nicer) IDE > by my brother Just? > > In either case, you are probably better of trying to learn Tkinter on > a Unix or Windows platform; it is unfortunately notoriously unstable > on the Mac, and there's not a lot we can do about this. > > --Guido van Rossum I'm not sure of terminology. I was trying to use what is called (on disk) "Python IDE" and whose About Box when running says "The Python Integrated Development Environment" version 1.0 by Just. I don't think I've seen anything else called IDE on the Mac. Just's note to me seems to confirm that I was using his environment, which he explains won't work with tkinter. So I'll stop trying that! I didn't expect to hear directly from you, Guido, in response to my bug report. Thanks for writing. Some colleagues and I were planning on talking with you in depth about your strong interest in computer programming for everybody, which is of deep concern to us, too. But we only just started learning Python and were going to hold off from approaching you until we knew enough not to seem total idiots. But since you took the time to write to me, I'm encouraged to play the half-idiot and indicate our interest now. We would welcome deeper discussion if you perceive a community of interest. We're 200% in agreement with your stirring essay. Ordinary mortals ought to be able to write computer programs! We ourselves have worked hard on this problem for 30 years, with significant but little-known success in the particular niche of college faculty and students writing interactive graphics-oriented educational software. We're very impressed by the quality of what you have done in creating Python, and we believe it can be a solid foundation for programming for everybody. The exceptionally clean syntax, uncluttered by semicolons and ends and brackets, is important for nonexperts. We think Python has the potential to be a better foundation than our own cT programming language, and we would like to explore ways in which to contribute to the goal and vision you have articulated. Not only do we have long and deep experience in making it possible for nonexperts to write interactive graphics programs, but we are also involved in teaching an introductory college physics course in which students do graphics-oriented programming to carry out computer modeling of physical systems. Many of these students have never written a program before (for the reasons you discuss), yet toward the end of just two 50-minute periods of instruction the students are writing a program to calculate and display the motion of a spacecraft going from the Earth to the Moon. They do many such computer modeling projects during the semester. And they do this on Windows, Mac, and Linux, with the language, the graphics, and the programming environment all identical on all machines, with trivially easy installation and use, unplagued by problems of search paths, etc. Concretely, here is what we can offer in support of your goal: 1) If a graphics-oriented, multiplatform, Python-based environment suitable for novices can be developed, we have a physics course that we teach in which its deployment could be tested. So we offer a potential testbed for your DARPA project. I note in your essay your interest in what the University of Chicago can provide as a testbed for teaching the language. We can broaden the range of issues to include the case of a physics course where little time can be spent teaching programming, since the focus is on the physics, not the computer science, and where scientific graphics is central to the enterprise. 2) We can contribute to the design of such an environment, based on our long experience of developing and teaching and using a graphics-oriented, multiplatform programming language accessible to nonexperts. One of my colleagues can offer significant system expertise with the Mac (in addition to expertise with Windows and Linux). Mac systems expertise seems to be in short supply in the nation, yet the Mac is still very important in many educational settings. 3) Another of my colleagues has a particularly strong interest in designing and implementing powerful 3D scientific graphics in a way that would be usable by novices, based on Python. The possibilities this opens up for our physics course provide one of the main reasons for our interest in going beyond what is practical within the structures of cT, mainly because cT is not really object-oriented. Note that this is a different graphics issue than the one explored by Randy Pausch: it isn't a question of using Python to manipulate 3D models but doing such things as planetary orbits in 3D, from first principles. An area that cries out for 3D visualization is magnetism, where magnetic fields are inherently 3D objects. Another colleague has produced 3D movies of electric and magnetic fields in space, but these are not interactive and should be, when that is possible in the future. As I said, we weren't going to approach you until we knew more about Python. One of the reasons I've signaled our interest prematurely is that we find we need some guidance in the graphics area. We've been playing with tkinter since it seemed to have the largest community, but apparently there are LOTS of graphics environments in use with Python. We need some advice on plausible directions to go for graphics, and what makes sense as a foundation for extending to 3D scientific computer animation usable by novices. We believe that good novice-friendly graphics are absolutely critical to computer programming for everybody. There certainly are some "everybodies" who mostly want and need to sort lists or calculate mathematical functions or search files. But in our experience what grabs most everybodies is the instant gratification of starting with graphics. In the first 50 minutes of instruction our students have blue balls bouncing around inside a red box. This is powerful stuff and highly motivating. To us, graphics is utterly central to the goal of computer programming for everybody. And it is critical to our physics course. Bruce Sherwood Center for Innovation in Learning and Department of Physics Carnegie Mellon University http://cil.andrew.cmu.edu/bruce.sherwood.html P.S. Sorry about reporting the tkinter bug with arcs to you rather than to the Tk people. I didn't quite see how to report it to them and figured that if I sent it to Python it would get to the right person eventually. I am now using oval rather than arc to avoid the bug, though in an algorithmic situation one might compute the extent of an arc, and if it comes out to be 360, too bad -- you'll get a line instead of an oval. From tim_one@email.msn.com Thu Jan 13 06:24:05 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 13 Jan 2000 01:24:05 -0500 Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) In-Reply-To: <200001122239.RAA10631@python.org> Message-ID: <000201bf5d8e$ca7270a0$d62d153f@tim> [ exec "x=x+1" vs exec compile("x=x+1", "", "exec") ] > *That* one's a bug -- the exec statement is supposed to > sync back the locals fron the dict to their fast form, > but the code to do that is only present when the argument > is a string. I'm fixing this as we speak. Guido, please take another look at Vadim's original report too. I believe I was too hasty in dismissing it. exec'ing f.func_code (as he did) really isn't the same as calling or exec'ing f() (as I did), so if the above is a bug (no argument from me), I expect Vadim's original case should also be considered broken. Or, if it's not, why it's not is excruciatingly subtle. From tim_one@email.msn.com Thu Jan 13 06:24:18 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Thu, 13 Jan 2000 01:24:18 -0500 (EST) Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) Message-ID: <200001130624.BAA23128@python.org> [ exec "x=x+1" vs exec compile("x=x+1", "", "exec") ] > *That* one's a bug -- the exec statement is supposed to > sync back the locals fron the dict to their fast form, > but the code to do that is only present when the argument > is a string. I'm fixing this as we speak. Guido, please take another look at Vadim's original report too. I believe I was too hasty in dismissing it. exec'ing f.func_code (as he did) really isn't the same as calling or exec'ing f() (as I did), so if the above is a bug (no argument from me), I expect Vadim's original case should also be considered broken. Or, if it's not, why it's not is excruciatingly subtle. From tim_one@email.msn.com Thu Jan 13 07:49:47 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Thu, 13 Jan 2000 02:49:47 -0500 (EST) Subject: [Python-bugs-list] popen2(make test) (PR#180) Message-ID: <200001130749.CAA24526@python.org> > Full_Name: Ryosuke Nakao > Version: 1.5.2 > OS: Solaris7 > Submission from: (NULL) (157.77.16.21) > When doing make test on the latest(as of 12 Jan 2000) > python version, the popen2 tests fails. Hi. This is a duplicate of bug #49. Go to http://www.python.org/python-bugs/resolved?user=guest;selectid=49 for a short patch (it's fixed in the current CVS version). From tim_one@email.msn.com Thu Jan 13 07:49:37 2000 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 13 Jan 2000 02:49:37 -0500 Subject: [Python-bugs-list] popen2(make test) (PR#180) In-Reply-To: <200001121237.HAA28440@python.org> Message-ID: <000501bf5d9a$bdba1960$d62d153f@tim> > Full_Name: Ryosuke Nakao > Version: 1.5.2 > OS: Solaris7 > Submission from: (NULL) (157.77.16.21) > When doing make test on the latest(as of 12 Jan 2000) > python version, the popen2 tests fails. Hi. This is a duplicate of bug #49. Go to http://www.python.org/python-bugs/resolved?user=guest;selectid=49 for a short patch (it's fixed in the current CVS version). From guido@CNRI.Reston.VA.US Thu Jan 13 12:29:23 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 13 Jan 2000 07:29:23 -0500 (EST) Subject: [Python-bugs-list] Exec statement inconsistency (PR#175) Message-ID: <200001131229.HAA01055@python.org> Tim Peters wrote: > Guido, please take another look at Vadim's original report too. I believe I > was too hasty in dismissing it. exec'ing f.func_code (as he did) really > isn't the same as calling or exec'ing f() (as I did), so if the above is a > bug (no argument from me), I expect Vadim's original case should also be > considered broken. Or, if it's not, why it's not is excruciatingly subtle. Tim, and Vadim: Even though Vadim made a good analysis and proposed a fix, I'm not going to change this (even if the fix is correct, which I can't judge without more testing than I have time for). *If* I have to make a change in response to this PR, I'm going to change it so that the exec statement will refuse the code of a function object, since this is the crux of the problem: while exec takes a code object, not all code objects are considered equal. The code object for a function is intended to take arguments and return a value, while a code object for the exec statement is intended to do neither. I don't see a particular good reason why one would *want* to execute the code object of a function independently, and I don't want the implementation of the language to be bound by this requirement. I can imagine all sorts of optimizations and other implementation techniques that would make it even harder to allow exec'ing f.func_code correctly, so I'd rather forbid this than work hard to allow it. Access to a function's code object is given for a different reason: a debugger or code analyzer can dig useful information out of it. Hope this explains it, --Guido van Rossum (home page: http://www.python.org/~guido/) From calvin@cs.uni-sb.de Thu Jan 13 16:00:41 2000 From: calvin@cs.uni-sb.de (calvin@cs.uni-sb.de) Date: Thu, 13 Jan 2000 11:00:41 -0500 (EST) Subject: [Python-bugs-list] strftime crashes with invalid args (PR#183) Message-ID: <200001131600.LAA12064@python.org> Full_Name: Bastian Kleineidam Version: 1.5.2 OS: Linux (Debian slink) Submission from: www-proxy.rz.uni-sb.de (134.96.7.81) test.py: import time # crash it by swapping year and month argument print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) python test.py Segmentation fault Well there were similar crashes with time.strptime calls. I think this is a platform bug with the C function strftime, but I did not test this in a C program. From guido@CNRI.Reston.VA.US Thu Jan 13 16:02:58 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 13 Jan 2000 11:02:58 -0500 (EST) Subject: [Python-bugs-list] strftime crashes with invalid args (PR#183) Message-ID: <200001131602.LAA12184@python.org> > Full_Name: Bastian Kleineidam > Version: 1.5.2 > OS: Linux (Debian slink) > Submission from: www-proxy.rz.uni-sb.de (134.96.7.81) > > > test.py: > import time > # crash it by swapping year and month argument > print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) > > python test.py > Segmentation fault > > Well there were similar crashes with time.strptime calls. I think this > is a platform bug with the C function strftime, but I did not test this > in a C program. Yes, this is a platform bug. Please report it to the C library folks (sorry, I can't do that for you). --Guido van Rossum (home page: http://www.python.org/~guido/) From calvin@void.cs.uni-sb.de Thu Jan 13 17:37:04 2000 From: calvin@void.cs.uni-sb.de (calvin@void.cs.uni-sb.de) Date: Thu, 13 Jan 2000 12:37:04 -0500 (EST) Subject: [Python-bugs-list] strftime crashes with invalid args (PR#183) Message-ID: <200001131737.MAA15855@python.org> [snip bug report] :) Yes, this is a platform bug. Please report it to the C library folks :) (sorry, I can't do that for you). Ok, did it. So the safe side is to check the arguments before calling time.strftime() Bastian Kleineidam From calvin@cs.uni-sb.de Thu Jan 13 18:39:00 2000 From: calvin@cs.uni-sb.de (calvin@cs.uni-sb.de) Date: Thu, 13 Jan 2000 13:39:00 -0500 (EST) Subject: [Python-bugs-list] strftime crashes with invalid args (PR#183) Message-ID: <200001131839.NAA18016@python.org> :) Yes, this is a platform bug. Please report it to the C library folks :) (sorry, I can't do that for you). I got answer from Andreas Jaeger that this bug is fixed with the current glibc version 2.1.2. Bastian Kleineidam From st99@mail.ru Mon Jan 17 13:30:02 2000 From: st99@mail.ru (st99@mail.ru) Date: Mon, 17 Jan 2000 08:30:02 -0500 (EST) Subject: [Python-bugs-list] bug in the module re (PR#184) Message-ID: <200001171330.IAA01047@python.org> Full_Name: Sultanbek Tezadov Version: 1.5.2 OS: Linux, Win32 Submission from: minas.rosmail.com (195.90.128.115) There is a bug in the re module: in MULTILINE and DOTALL mode the .*? pattern is greedy for newlines (^). E.g.: >>> import re >>> s = """\ ... line 1 ... line 2 ... ... ... line n ... """ >>> def f(s, p): ... print re.search(p, s).group(1) ... >>> p = r'(?m)(^.*?2)' # it works okay >>> f(s, p) line 2 >>> p = r'(?ms)(^.*?2)' # but for some reasons I need DOTALL mode as well >>> f(s, p) # I expect the same output as before, but I get: line 1 line 2 >>> I got it both on Linux and Win32. From guido@CNRI.Reston.VA.US Mon Jan 17 14:04:30 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 17 Jan 2000 09:04:30 -0500 (EST) Subject: [Python-bugs-list] bug in the module re (PR#184) Message-ID: <200001171404.JAA02002@python.org> > Full_Name: Sultanbek Tezadov > Version: 1.5.2 > OS: Linux, Win32 > Submission from: minas.rosmail.com (195.90.128.115) > > > There is a bug in the re module: in MULTILINE and DOTALL mode > the .*? pattern is greedy for newlines (^). E.g.: > >>> import re > >>> s = """\ > ... line 1 > ... line 2 > ... ... > ... line n > ... """ > >>> def f(s, p): > ... print re.search(p, s).group(1) > ... > >>> p = r'(?m)(^.*?2)' # it works okay > >>> f(s, p) > line 2 > >>> p = r'(?ms)(^.*?2)' # but for some reasons I need DOTALL mode as well > >>> f(s, p) # I expect the same output as before, but I get: > line 1 > line 2 > >>> > > I got it both on Linux and Win32. I don't think this is a bug. In dotall mode, . matches \n. The matcher finds ^ at the start of line 1, and then matches more and more characters until it finds a 2. Since . matches \n, it matches the first two lines. --Guido van Rossum (home page: http://www.python.org/~guido/) From tage@acm.org Tue Jan 18 18:46:13 2000 From: tage@acm.org (tage@acm.org) Date: Tue, 18 Jan 2000 13:46:13 -0500 (EST) Subject: [Python-bugs-list] ConfigParser (file not closed) (PR#185) Message-ID: <200001181846.NAA08886@python.org> Full_Name: Tage Stabell-Kulø Version: 1.5.2 OS: All Submission from: dibbler.uit.no (129.242.4.34) In library module ConfigParser, I believe the following patch should be applied: --- ConfigParser.py Tue Jan 18 19:41:04 2000 *************** *** 173,178 **** --- 173,179 ---- try: fp = open(file, 'r') self.__read(fp) + fp.close() except IOError: pass ========= I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From guido@CNRI.Reston.VA.US Tue Jan 18 18:49:28 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 18 Jan 2000 13:49:28 -0500 (EST) Subject: [Python-bugs-list] ConfigParser (file not closed) (PR#185) Message-ID: <200001181849.NAA08954@python.org> > In library module ConfigParser, I believe the following patch > should be applied: > > --- ConfigParser.py Tue Jan 18 19:41:04 2000 > *************** > *** 173,178 **** > --- 173,179 ---- > try: > fp = open(file, 'r') > self.__read(fp) > + fp.close() > except IOError: > pass Thanks, you're right. This is already fixed in our CVS tree (it was done as part of some reorganization). --Guido van Rossum (home page: http://www.python.org/~guido/) From hauser@eos.ncsu.edu Fri Jan 21 13:36:29 2000 From: hauser@eos.ncsu.edu (hauser@eos.ncsu.edu) Date: Fri, 21 Jan 2000 08:36:29 -0500 (EST) Subject: [Python-bugs-list] Page fault in module KERNEL32.DLL (PR#186) Message-ID: <200001211336.IAA28712@python.org> Full_Name: John R. Hauser Version: 1.5.2 OS: windows 95 Submission from: director.aemp.ncsu.edu (152.1.191.158) I am new to Python and am having a problem on Windows 95 any time I use the Tkinter module. An example follows: >>>from Tkinter import * >>>t = Button(None, {'text': 'Test', Pack: {}}) >>>q = Button(None, {'text': 'Quit', 'command': t.quit, Pack: {}}) >>>t.mainloop() The window comes up and seems to work. Clicking on the 'Quit' button returns to the Python screen. Then: >>>Ctrl-D ->message comes up that illegal operation has been perforned: Page fault in KERNEL32.DLL at 016f:6ff79ff3, computer hangs and has to be hard booted. Everything else seems to work, the idle program comes up and everything is OK until I try to exit and the same problem happens. If I don't use Tkinter I don't have the problem and any time with Tkinter I make a window and exit from the window, and try to exit Python the same error appears. I have found several references to Page faults in KERNEL32 in the Bug reports but have not seen any solutions. Any help would be appreciated. Thanks. From aa8vb@yahoo.com Mon Jan 24 16:19:13 2000 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Mon, 24 Jan 2000 11:19:13 -0500 (EST) Subject: [Python-bugs-list] Operator breakage with long int operands (PR#187) Message-ID: <200001241619.LAA21351@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5 Submission from: ralph.rtpnc.epa.gov (134.67.66.44) This came up a few weeks ago, and bit again in the dumbdbm module last week. In the dumbdbm module in 1.5.2: '\0'*(npos-pos) (npos-pos) on some OSs will be a long int. However, the '*' operator won't handle a long int. I can't think of a reason why 'a'*10L should be invalid, for example. At issue a few weeks ago was long ints and the '%' operator. For example: >>> str( 0x80000000L ) '2147483648L' >>> "%ld" % 0x80000000L OverflowError: long int too long to convert >>> hex( 0x80000000L ) '0x80000000L' >>> "%lX" % 0x80000000L OverflowError: long int too long to convert Couldn't % use hex() and str() under the hood, for instance? From tage@acm.org Mon Jan 24 16:56:47 2000 From: tage@acm.org (tage@acm.org) Date: Mon, 24 Jan 2000 11:56:47 -0500 (EST) Subject: [Python-bugs-list] dircache not kept consistent (PR#188) Message-ID: <200001241656.LAA22031@python.org> Full_Name: Tage Stabell-Kulø Version: 1.5.2 OS: FreeBSD Submission from: (NULL) (129.242.16.231) The documentation for the dircache module states: "Return a directory listing of path, as gotten from os.listdir(). Note that unless path changes, further call to listdir() will not re-read the directory structure. " The following program demonstrates that this is misleading (at best): #! /usr/bin/env python import whrandom import os import dircache import string generator = whrandom.whrandom() while 1: dirlist = dircache.listdir(".") files = [] while 1: file = "" for i in range(10): file = file + string.hexdigits[generator.randint(0,15)] files.append(file); fd = open(file, "w") fd.close() if file in dircache.listdir("."): break print "Created %d files" % len(files) for i in files: os.unlink(i) The output (on my FreeBSD machine) is Created 28 files Created 69 files Created 48 files Created 58 files Created 53 files In my view, this is an outright bug. I suggest that either the documentation is changed to say: The cache is updated only once a second. The reason is, of cource, that the st_mtime field is a time_t and holds seconds. Or, better, change posixmodule.c with this patch (more text after the patch) ====== --- posixmodule.c.org Mon Jan 24 17:08:06 2000 +++ posixmodule.c Mon Jan 24 17:31:39 2000 @@ -559,7 +559,7 @@ (long)st.st_mtime, (long)st.st_ctime); #else - return Py_BuildValue("(lLllllLlll)", + return Py_BuildValue("(lLllllLllll)", (long)st.st_mode, (LONG_LONG)st.st_ino, (long)st.st_dev, @@ -569,7 +569,8 @@ (LONG_LONG)st.st_size, (long)st.st_atime, (long)st.st_mtime, - (long)st.st_ctime); + (long)st.st_ctime, + (long)st.st_mtimespec.tv_nsec); #endif } @@ -2637,7 +2638,7 @@ (long)st.st_mtime, (long)st.st_ctime); #else - return Py_BuildValue("(lLllllLlll)", + return Py_BuildValue("(lLllllLllll)", (long)st.st_mode, (LONG_LONG)st.st_ino, (long)st.st_dev, @@ -2647,7 +2648,8 @@ (LONG_LONG)st.st_size, (long)st.st_atime, (long)st.st_mtime, - (long)st.st_ctime); + (long)st.st_ctime, + (long)st.st_mtimespec.tv_nsec); #endif } ====== and apply the following patch to the dircache module: +++ dircache.py Mon Jan 24 17:48:53 2000 @@ -15,7 +15,11 @@ except KeyError: cached_mtime, list = -1, [] try: - mtime = os.stat(path)[8] + st = os.stat(path) + if len(st) == 11: + mtime = st[10] + else: + mtime = st[8] except os.error: return [] if mtime <> cached_mtime: I appreciate your effort to maintain Python; I hope you find my small contribution useful. ===================================================================== I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From gudo@python.org Mon Jan 24 19:27:26 2000 From: gudo@python.org (gudo@python.org) Date: Mon, 24 Jan 2000 14:27:26 -0500 (EST) Subject: [Python-bugs-list] .pyc writing/reading race condition (PR#189) Message-ID: <200001241927.OAA24922@python.org> Full_Name: GvR Version: 1.5.2 OS: any Submission from: (NULL) (204.254.19.46) Patrick Miller reminded me that there's still a race condition in the reading and writing of .pyc files. If two processes decide to write the .pyc, and a third reads the header after the first complete but before the second starts, but reads the rest of the file after the second starts but before it is done, the third can read corrupt data (and won't fall back to reading the .py source). Solution: when writing the .pyc file, (1) unlink the file before writing, (2) use open() with the Unix flags that fail creation if the file exists (and then just treat it like any open failure when writing the .pyc file). From ajung@sz-sb.de Tue Jan 25 07:21:16 2000 From: ajung@sz-sb.de (ajung@sz-sb.de) Date: Tue, 25 Jan 2000 02:21:16 -0500 (EST) Subject: [Python-bugs-list] strop.lowercase/uppercase delivers too much characters (PR#190) Message-ID: <200001250721.CAA11587@python.org> Full_Name: Andreas Jung Version: 1.5.2 OS: Solaris 2.7 Submission from: saarland.sz-sb.de (212.88.192.10) tedint@/usr/local/sourcen/Python-1.5.2(3)% ./python Python 1.5.2 (#4, Jan 25 2000, 08:13:46) [GCC 2.95.1 19990816 (release)] on sun os5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import strop >>> strop.lowercase 'abcdefghijklmnopqrstuvwxyz\337\340\341\342\343\344\345\346\347\350\351\352\353\ 354\355\356\357\360\361\362\363\364\365\366\370\371\372\373\374\375\376\377' >>> strop.uppercase 'ABCDEFGHIJKLMNOPQRSTUVWXYZ\300\301\302\303\304\305\306\307\310\311\312\313\314\ 315\316\317\320\321\322\323\324\325\326\330\331\332\333\334\335\336' >>> Instead of delivering just 'a'-'z' I got much more characters. This problem occurs only on Solaris 2.7 machines Andreas Jung From Tage@ACM.org Tue Jan 25 08:35:07 2000 From: Tage@ACM.org (Tage@ACM.org) Date: Tue, 25 Jan 2000 03:35:07 -0500 (EST) Subject: [Python-bugs-list] Re: dircache not kept consistent (PR#188) Message-ID: <200001250835.DAA12523@python.org> [On the problem with rare updates of the cache in the dircache library module] Guido van Rossum wrote: >However, if milliseconds precision is available for the mtime, >it could be added to the Python mtime value (which is represented >as a float). > >Do you think you could provide a patch for that? Will do. >--Guido van Rossum //// Tage Stabell-Kuloe | e-mail: tage at ACM.org (at=@)//// /// Department of Computer Science/IMR | Phone : +47-776-44032 /// // 9037 University of Tromsoe, Norway | Fax : +47-776-44580 // / "'oe' is '\o' in TeX" | URL:http://www.cs.uit.no/~tage/ From gurney_j@efn.org Tue Jan 25 17:33:53 2000 From: gurney_j@efn.org (gurney_j@efn.org) Date: Tue, 25 Jan 2000 12:33:53 -0500 (EST) Subject: [Python-bugs-list] undefined symbol in custom interpeter (PR#191) Message-ID: <200001251733.MAA24199@python.org> Full_Name: John-Mark Gurney Version: 1.5.2 OS: FreeBSD 3.4R Submission from: adsl-63-195-54-213.dsl.snfc21.pacbell.net (63.195.54.213) When I try to run the following program I get an undefined symbol on PyDict_SetString. #include void main() { Py_Initialize(); PyRun_SimpleString("import base64\n"); Py_Finalize(); } I believe this is because the interpeter library doesn't reference all of the symbols that it may need when loading modules. So the linker will throw out any unecessary symbols which happen to include PyDict_SetString. I tried to include PyDict_SetString into my program, but was unable to make it work. From davidv@elisra.com Thu Jan 27 18:31:19 2000 From: davidv@elisra.com (davidv@elisra.com) Date: Thu, 27 Jan 2000 13:31:19 -0500 (EST) Subject: [Python-bugs-list] readline on QNX (PR#192) Message-ID: <200001271831.NAA04509@python.org> Full_Name: David Vainapel Version: 1.52 OS: Qnx Submission from: pop09-1-ras1-p215.barak.net.il (212.150.8.215) This is not a bug. I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't work good with QNX. This simple patch for /Parser/myreadline.c replaces readline with QNX input_line function. ------------------------------------------------------------ 60,68d59 < < #ifdef __QNX__ < p = input_line( fp, buf, len ); < if( p ) { < int n = strlen(p); < p[n] = '\n'; < p[n+1] = 0; < } < #else 70d60 < #endif ------------------------------------------------------------- From hauser@eos.ncsu.edu Thu Jan 27 20:33:42 2000 From: hauser@eos.ncsu.edu (hauser@eos.ncsu.edu) Date: Thu, 27 Jan 2000 15:33:42 -0500 (EST) Subject: [Python-bugs-list] Re: Page fault in module KERNEL32.DLL (PR#186) Message-ID: <200001272033.PAA06560@python.org> Guido, Thanks very much for your help. With your suggestion I have traced the problem to a file CSINJECT.exe which was being loaded on startup. This is a file associated with the Norton Clean Sweep utility. After removing it from my startup file, everything works fine. I guess it was loaded when I installed Norton Utilities and I have no idea what it does. Thanks again for you thoughts. John Hauser At 02:47 PM 1/24/2000 -0500, you wrote: >John, > >I am afraid I can't reproduce your problem, and I've never heard >of this type of behavior before. > >My best guess is that some other Windows app that you have installed >is causing this behavior; this is basically impossible to debug. > >I suggest that you post your problem description to comp.lang.python; >maybe someone there has a clever idea. If you find a solution, please >reply to this message, leaving the subject intact. > >In the mean time, I;ll keep your bug report in the "irreproducuble" >category. > >Thanks, > >--Guido van Rossum > > > From DrMalte@ddd.de Mon Jan 31 00:40:47 2000 From: DrMalte@ddd.de (DrMalte@ddd.de) Date: Sun, 30 Jan 2000 19:40:47 -0500 (EST) Subject: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Message-ID: <200001310040.TAA25232@python.org> Full_Name: Malte John Version: 1.5.2 and 1.4 OS: Linux Submission from: router.ddd.de (212.105.193.65) While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing . The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) From gurney_j@resnet.uoregon.edu Mon Jan 31 02:08:44 2000 From: gurney_j@resnet.uoregon.edu (gurney_j@resnet.uoregon.edu) Date: Sun, 30 Jan 2000 21:08:44 -0500 (EST) Subject: [Python-bugs-list] please resolve 191.. (PR#195) Message-ID: <200001310208.VAA26697@python.org> I have found out that I need to add -Xlinker -export-dynamic to the gcc command to compile a program linked w/ the libpython.a library... if you do not specify this option, all unreferenced symbols will be discarded... please document this requirement in the documentation, and after that has happened, close this bug report... Thanks. -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson From guido@CNRI.Reston.VA.US Mon Jan 31 17:24:31 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 31 Jan 2000 12:24:31 -0500 (EST) Subject: [Python-bugs-list] please resolve 191.. (PR#195) Message-ID: <200001311724.MAA20828@python.org> > I have found out that I need to add -Xlinker -export-dynamic to the gcc > command to compile a program linked w/ the libpython.a library... if you > do not specify this option, all unreferenced symbols will be discarded... > > please document this requirement in the documentation, and after that has > happened, close this bug report... I read your bug report 191 and I think it may be platform specific, or a bug in how you link with Python, since I cannot reproduce this here on Solaris. Until we are clear on this we can't fix the documentation, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Mon Jan 31 17:27:39 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 31 Jan 2000 12:27:39 -0500 (EST) Subject: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Message-ID: <200001311727.MAA20911@python.org> Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) From gurney_j@resnet.uoregon.edu Mon Jan 31 19:39:09 2000 From: gurney_j@resnet.uoregon.edu (gurney_j@resnet.uoregon.edu) Date: Mon, 31 Jan 2000 14:39:09 -0500 (EST) Subject: [Python-bugs-list] please resolve 191.. (PR#195) Message-ID: <200001311939.OAA23715@python.org> Guido van Rossum scribbled this message on Jan 31: > > I have found out that I need to add -Xlinker -export-dynamic to the gcc > > command to compile a program linked w/ the libpython.a library... if you > > do not specify this option, all unreferenced symbols will be discarded... > > > > please document this requirement in the documentation, and after that has > > happened, close this bug report... > > I read your bug report 191 and I think it may be platform specific, or > a bug in how you link with Python, since I cannot reproduce this here > on Solaris. I would try it under Solaris, but I don't have the time right now to compile up the latest GNU ld on solaris, to make sure that it is compiler specific... > Until we are clear on this we can't fix the documentation, sorry. I would think that you would want to document such a behavior considering just how many people happen to use gcc... I am using gcc 2.7.2.3 and GNU ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1, I would assume you'd want to document it so that people like myself, don't run into this problem... the -Xlinker -export-dynamic happens to be a GNU ld specific solution, but the bug that python doesn't force include all the symbols should be documented so that people don't encounter the problem... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson From guido@CNRI.Reston.VA.US Mon Jan 31 20:34:39 2000 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 31 Jan 2000 15:34:39 -0500 (EST) Subject: [Python-bugs-list] please resolve 191.. (PR#195) Message-ID: <200001312034.PAA24735@python.org> > Guido van Rossum scribbled this message on Jan 31: > > > I have found out that I need to add -Xlinker -export-dynamic to the gcc > > > command to compile a program linked w/ the libpython.a library... if you > > > do not specify this option, all unreferenced symbols will be discarded... > > > > > > please document this requirement in the documentation, and after that has > > > happened, close this bug report... > > > > I read your bug report 191 and I think it may be platform specific, or > > a bug in how you link with Python, since I cannot reproduce this here > > on Solaris. > > I would try it under Solaris, but I don't have the time right now to > compile up the latest GNU ld on solaris, to make sure that it is compiler > specific... > > > Until we are clear on this we can't fix the documentation, sorry. > > I would think that you would want to document such a behavior considering > just how many people happen to use gcc... I am using gcc 2.7.2.3 and GNU > ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1, > I would assume you'd want to document it so that people like myself, don't > run into this problem... > > the -Xlinker -export-dynamic happens to be a GNU ld specific solution, > but the bug that python doesn't force include all the symbols should be > documented so that people don't encounter the problem... This (that it's GNU ld specific) is information that you didn't explain first. I am probably not using GNU ld, which may explain why I couldn't reproduce your problem. If you want to save me the most time, please suggest the exact patch for the documentation, using the latest version of the docs from the CVS tree. (python.org/download/cvs.html) To save me at least some time, write a paragraph of text and give me at least a hint on which section of which document it should be inserted into, and we'll figure it out from there. --Guido van Rossum (home page: http://www.python.org/~guido/)