[ python-Bugs-1609958 ] tarfile archive paths limited to less than 100 chars
Bugs item #1609958, was opened at 2006-12-06 10:58 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=1609958&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: Frank Rehberger (frehberg) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile archive paths limited to less than 100 chars Initial Comment: The tarfile-module 0.8 shipped with Python-2.5 fails to handle archive-paths longer than 100 chars, in posix mode and GNU-mode. AFAICS, the path-length limit should be 256 for posix-mode and infinite for GNU-mode. The last tarfile module I know, being able to handle long paths is tarfile-0.7.4. Attached you will find a test-script. The script prints the tarfile.version you are using to console and runs two tests, one for posix-mode up to path-length 256 and a second test for GNU-mode with pathlengths up to 1024. ### ###Testoutput with Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /home/frehberg/tmp/bin/python Tarfile Version: 0.8.0 TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=True) TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=False) ### ###Workarround for Python-2.5 ### (Assuming you are using Linux and Python-2.5 has been installed with prefix /usr/local/) Download tarfile-0.7.4 from http://www.gustaebel.de/lars/tarfile/ and run: ## remove original tarfile-module shipped with ## python2.5 rm -rf /usr/local/lib/python2.5/tarfile.py* ## install tarfile-0.7.4 tar -xvz -C /tmp/ -f /net/linux/pkg/python/tarfile-0.7.4.tar.gz cd /tmp/tarfile-0.7.4/ /usr/local/bin/python2.5 setup.py install ### ###Testoutput with patched Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /usr/local/bin/python Tarfile Version: 0.7.4 Tarfile module (posix=True) is Ok Tarfile module (posix=False) is Ok -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 04:49 Message generated for change (Comment added) made by mikepowers48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. Löwis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 07:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-05 23:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff -- Comment By: Daniel Eloff (eloff) Date: 2006-12-05 19:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. -- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 06:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 20:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? -- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 05:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC005: Access violation reading location 0x0034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e03ac82() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e() python25.dll!1e
[ python-Bugs-1606092 ] csv module broken for unicode
Bugs item #1606092, was opened at 2006-11-30 08:46 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&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: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: Nobody/Anonymous (nobody) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? -- >Comment By: Skip Montanaro (montanaro) Date: 2006-12-06 09:56 Message: Logged In: YES user_id=44345 Originator: NO > Anyone know why it uses a C extension? Performance. A number of people (among them the authors of the _csv extension and me, a contributor to the Python csv module that fronts it) routinely read and write large (several megabytes) CSV files. We had all had experience with earlier Python-only CSV readers and writers. Their performance was just too poor. If you wrote a new module in Python that's compatible with the existing module -- and performed acceptably -- I see no reason it couldn't replace the current module. There are already a number of test cases. You'd certainly have to embellish them, but if the current set passed that would be a good indication your code was at least on the right track compatibility-wise. There are other reasons to desire a Python-based solution other than Unicode support. It would be much more likely that such a module would work with other Python implementations (e.g., PyPy, IronPython and Jython). Skip -- Comment By: JettLogic (jettlogic) Date: 2006-12-05 05:53 Message: Logged In: YES user_id=1345991 Originator: YES Anyone know why it uses a C extension? The C code apparently appends fields to a writable byte buffer (so patching for unicode is impossible), reallocated as it grows. How much efficiency is gained by doing that, with its many lines of logic overhead, versus careful use of python strings? For montanaro, the UnicodeWriter with three coding conversions and a StringIO shows there is however much efficiency to be lost. Perhaps lemburg's suggestion of a pure-python re-implementation of _csv is the way to go. It does not look like a fun task, after adding in back-compatibility, benchmarks and tests, and I couldn't commit to it just yet. Are C->Py patches typically accepted? (assume quality code and comparable benchmarks) I'll have to leave it at that. If you leave this open, someone might take it up at some point. -- Comment By: Skip Montanaro (montanaro) Date: 2006-12-03 12:22 Message: Logged In: YES user_id=44345 Originator: NO I must admit I don't understand the criticism of the UnicodeReader and UnicodeWriter example classes in the module documentation. Sure, their implementations jump through some hoops, but that's so you don't have to. If you use them as written I believe their API's should be about the same as the csv.reader and csv.writer classes with the added improvement that the reader returns Unicode and the writer accepts Unicode. If your desire is to read and write Unicode why do you care that those objects are encoded using utf-8 in the file? Like Martin asked, are you willing to come up with better examples? Better yet, are you willing to provide a patch for the underlying extension module so it handles Unicode? Hint: I'm fairly certain that if it was trivial it would have been done by now. -- Comment By: M.-A. Lemburg (lemburg) Date: 2006-12-03 06:54 Message: Logged In: YES user_id=38388 Originator: NO It should be easy to provide a wrapper class which implements the above in plain Python. However, if noone volunteers to write such code, it's not going to happen
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 04:49 Message generated for change (Comment added) made by eloff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. Löwis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 10:43 Message: Logged In: YES user_id=730918 Originator: NO Thanks Martin, I applied the patch. The problem I was having was the IO Error, sorry for being vague. The part I don't understand is I should not have had other threads running (and definately should not have had the logger being used outside the main thread.) Can the problem occur with just one thread? I was running under the debugger in wing, I don't know if that might cause this problem. Anyway if I find out anything else I'll let you know. If you don't hear from me then everything is working great. -- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 07:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-05 23:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff -- Comment By: Daniel Eloff (eloff) Date: 2006-12-05 19:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. -- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 06:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-27 20:29 Message: Logged In: YES user_id=21627 Can you provide a test case for either problem? -- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-27 05:01 Message: Logged In: YES user_id=1007725 And I think python crashes on Windows if I try to use logger from several threads. Unhandled exception at 0x7c901010 in python.exe: 0xC005: Access violation reading location 0x0034. > ntdll.dll!7c901010() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcr71.dll!7c34f639() msvcr71.dll!7c36b3b1() python25.dll!1e06c6c0() python25.dll!1e08dc97() python25.dll!1e03ac12() python25.dll!1e03c735() python25.dll!1e03cc5f() python25.dll!1e04026b() python25.dll!1e039a2e(
[ python-Bugs-1566280 ] Logging problem on Windows XP
Bugs item #1566280, was opened at 2006-09-27 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Pavel Krupets (pavel_krupets) Assigned to: Martin v. Löwis (loewis) Summary: Logging problem on Windows XP Initial Comment: Traceback (most recent call last): File "C:\Python\Lib\logging\handlers.py", line 73, in emit if self.shouldRollover(record): File "C:\Python\Lib\logging\handlers.py", line 147, in shouldRollover self.stream.seek(0, 2) #due to non-posix-compliant Windows feature ValueError: I/O operation on closed file not sure why this file is closed. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-12-06 19:58 Message: Logged In: YES user_id=21627 Originator: NO eloff: It may be that there are different problems that all show the symptom; *this* problem reported here can only occur if you are using multiple threads (atleast for the ValueError; haven't looked into the crash at all). Yes, you can run multiple threads, and yes, you can use logging freely. However, you should not let the main thread just "run off". Instead, you should end your main thread with an explicit .join() operation on all threads it has created; those threads themselves should perform explicit .join() operations on all threads they create. That way, you can guarantee orderly shutdown. threading.py tries to do the joining if you don't, but fails (and the approach it uses is inherently error-prone). -- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 19:43 Message: Logged In: YES user_id=730918 Originator: NO Thanks Martin, I applied the patch. The problem I was having was the IO Error, sorry for being vague. The part I don't understand is I should not have had other threads running (and definately should not have had the logger being used outside the main thread.) Can the problem occur with just one thread? I was running under the debugger in wing, I don't know if that might cause this problem. Anyway if I find out anything else I'll let you know. If you don't hear from me then everything is working great. -- Comment By: Mike Powers (mikepowers48) Date: 2006-12-06 16:22 Message: Logged In: YES user_id=1614975 Originator: NO I'm seeing the I/O error and crash a lot on Windows and the I/O error on Linux. Any help would be greatly appreciated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-06 08:29 Message: Logged In: YES user_id=21627 Originator: NO Ok, so tsample.zip is a test case for the original problem, right? I can reproduce the problem on Linux also. I can't make it crash (on Linux); what do have to do to make it crash? If I access localhost:8080, I get log messages saying 2006-12-06 07:21:06,999 INFO servlet::__init__:1091 code 404, message File not found eloff: this report actually reports two problems (the I/O error, and the crash). Which of these are you having and have found lots of people having? As for the traceback problem: this is due to the main thread terminating, and therefore the logging atexit handler getting invoked, which closes the file. Only then is the threading atexit handler invoked, which waits until all non-daemon threads terminate. As a work-around, add httpServer.join() at the end of your script. I'll attach a patch that fixes this problem in the Python library. File Added: threading.diff -- Comment By: Daniel Eloff (eloff) Date: 2006-12-06 04:05 Message: Logged In: YES user_id=730918 Originator: NO I have this problem, I'm googling this and finding lots of people having the same problem. I'm running python 2.5 on windows XP and using the rotating file handler. I've disabled the logger in my application so I can continue development. -- Comment By: Pavel Krupets (pavel_krupets) Date: 2006-09-29 15:52 Message: Logged In: YES user_id=1007725 to start application please use: src/py/run.bat to get closed handler error (if you manage to start it) please open your web browser and try to visit: http://localhost:8080 You can change http settings in src/conf/development/robot.conf sorry code is quite raw just started. :) -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-28 05:29 Message: Logged
[ python-Bugs-1609958 ] tarfile archive paths limited to less than 100 chars
Bugs item #1609958, was opened at 2006-12-06 09:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Frank Rehberger (frehberg) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile archive paths limited to less than 100 chars Initial Comment: The tarfile-module 0.8 shipped with Python-2.5 fails to handle archive-paths longer than 100 chars, in posix mode and GNU-mode. AFAICS, the path-length limit should be 256 for posix-mode and infinite for GNU-mode. The last tarfile module I know, being able to handle long paths is tarfile-0.7.4. Attached you will find a test-script. The script prints the tarfile.version you are using to console and runs two tests, one for posix-mode up to path-length 256 and a second test for GNU-mode with pathlengths up to 1024. ### ###Testoutput with Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /home/frehberg/tmp/bin/python Tarfile Version: 0.8.0 TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=True) TarFile pathlength check failed, do not use!! failed for tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/tmp/fooo (length 100, posix=False) ### ###Workarround for Python-2.5 ### (Assuming you are using Linux and Python-2.5 has been installed with prefix /usr/local/) Download tarfile-0.7.4 from http://www.gustaebel.de/lars/tarfile/ and run: ## remove original tarfile-module shipped with ## python2.5 rm -rf /usr/local/lib/python2.5/tarfile.py* ## install tarfile-0.7.4 tar -xvz -C /tmp/ -f /net/linux/pkg/python/tarfile-0.7.4.tar.gz cd /tmp/tarfile-0.7.4/ /usr/local/bin/python2.5 setup.py install ### ###Testoutput with patched Python-2.5 ### > /usr/local/bin/python2.5 check-tarfile-module.py Python Version: 2.5 (r25:51908, Dec 6 2006, 10:13:25) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47)] Executable: /usr/local/bin/python Tarfile Version: 0.7.4 Tarfile module (posix=True) is Ok Tarfile module (posix=False) is Ok -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-06 22:22 Message: Logged In: YES user_id=849994 Originator: NO This was fixed by patch #1610437, thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1609958&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish
Bugs item #1610485, was opened at 2006-12-06 18:44 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=1610485&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Nobody/Anonymous (nobody) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from [EMAIL PROTECTED] was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish
Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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: IDLE Group: Python 2.5 >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) >Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from [EMAIL PROTECTED] was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-07 00:53 Message: Logged In: YES user_id=149084 Originator: NO I have not seen anything like this myself on W2K or WinXP, nor have I heard of something like this before. We switched to the subprocess version of IDLE at 2.3. When printing a mass of text to the Shell window, IDLE is about 30% slower when using the subprocess, but that doesn't sound like what you are reporting. When I move IDLE's windows around there is no perceptible delay, nor can I detect any slowness when typing. (The 30% isn't involved when doing that). I can run i = 1 while True: i +=1 print i and the GUI responds quickly even though the cpu is near 100%. If the solution works for you, fine, but it seems likely to me that there is something misconfigured with your Windows installation or that it is compromised by spyware or otherwise overloaded or having a hardware problem. I'm setting this bug as pending, works for me unless you can come up with something more definitive. What does your Task Manager show for CPU utilization when you are having this problem? It seems that something is hogging your cpu or you have a very slow computer. What's the clock rate and memory size? If you are running an internal firewall, try disconnecting from the net and turn off the firewall temporarily to see if the problem is there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
