[ python-Bugs-1771558 ] minor bug in turtle
Bugs item #1771558, was opened at 2007-08-10 11:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771558&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in turtle Initial Comment: xpc17:~:$ python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import turtle >>> turtle.demo2() Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.5/lib-tk/turtle.py", line 874, in demo2 sleep(2) NameError: global name 'sleep' is not defined Sleep needs to be imported from the time module before it is used. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-10 17:32 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 56900. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771558&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771260 ] Errors in site.py not reported properly
Bugs item #1771260, was opened at 2007-08-09 15:37 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) [EMAIL PROTECTED]:~/src/python-p3yk/build$ make object : type: TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the "lost sys.stderr" line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief "stderr unavailable; original exception was ..." message. -- >Comment By: Adam Olsen (rhamphoryncus) Date: 2007-08-10 12:19 Message: Logged In: YES user_id=12364 Originator: YES Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead. That way the callers can add the message about "lost sys.stderr" themselves, rather than it being interspersed in their output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771558 ] minor bug in turtle
Bugs item #1771558, was opened at 2007-08-10 11:30 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=1771558&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in turtle Initial Comment: xpc17:~:$ python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import turtle >>> turtle.demo2() Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.5/lib-tk/turtle.py", line 874, in demo2 sleep(2) NameError: global name 'sleep' is not defined Sleep needs to be imported from the time module before it is used. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771558&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771483 ] another 'nothing to repeat'
Bugs item #1771483, was opened at 2007-08-10 08:56
Message generated for change (Settings changed) made by viciousdog
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771483&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: Regular Expressions
Group: Python 2.5
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: viciousdog (viciousdog)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: another 'nothing to repeat'
Initial Comment:
Hi,
rxSlice = re.compile('\[([^:\]]*):([^:\[]?){1}(:[^:\[]+)?\]')
compiles, but
rxSlice = re.compile('\[([^:\]]*):([^:\[]*){1}(:[^:\[]+)?\]')
produces: >>> error: nothing to repeat
(Python 2.5.1 in idle on Windows XPpro)
Perhaps that 'nothing to repeat' is intended for {x} (i wouldn't like that at
all), but then it must not differenciate between * and ?.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771483&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771483 ] another 'nothing to repeat'
Bugs item #1771483, was opened at 2007-08-10 08:56
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=1771483&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: Regular Expressions
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: viciousdog (viciousdog)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: another 'nothing to repeat'
Initial Comment:
Hi,
rxSlice = re.compile('\[([^:\]]*):([^:\[]?){1}(:[^:\[]+)?\]')
compiles, but
rxSlice = re.compile('\[([^:\]]*):([^:\[]*){1}(:[^:\[]+)?\]')
produces: >>> error: nothing to repeat
(Python 2.5.1 in idle on Windows XPpro)
Perhaps that 'nothing to repeat' is intended for {x} (i wouldn't like that at
all), but then it must not differenciate between * and ?.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1771483&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 01:12 Message generated for change (Comment added) made by mwtoews You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&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: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 14:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. -- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 05:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 02:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 02:34 Message generated for change (Comment added) made by marhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Mark Harrison (marhar) Date: 2007-08-10 13:01 Message: Logged In: YES user_id=40482 Originator: NO I think this should be considered a bug. These two command lines (on unix) should behave the same: cat | ./foo.py ./foo.py But they do not. The first (using cat) behaves typically, needing only one control-D. The second needs the two control-D's as noted. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-25 11:04 Message: Logged In: YES user_id=984087 Originator: NO BTW, I opened bug 1643712 for doc change. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-24 09:20 Message: Logged In: YES user_id=984087 Originator: NO I tested two kinds of inputs with iter and noiter verisons. I posted "noter" code and OP's code is the iter version. 1) For input without newline at all (line1) behaves same with both versions. 2) The noiter version prints "eof" with "line1\n" while the iter version requires an additional CTRL-D. This is because iter version uses read ahead which is implemented using fread() . A simple C program using fread() behaves exactly same way. I tested on Linux but am sure windows behaviour (as posted by gagenellina) will have same reasons. Since the issue is with platform's stdio library, I don't think python should fix anything here. However, it may be worthwhile to mention something about this in documentation. I will open a bug for this purpose. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 09:45 Message: Logged In: YES user_id=984087 Originator: NO Ok. This may sound stupid but I couldn't find a way to attach a file to this bug report. So I am copying the code here: import sys line = sys.stdin.readline() while (line): print line, line = sys.stdin.readline() print "eof" * -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 09:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 08:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 08:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above describ
