[ python-Bugs-1339045 ] Threading misbehavior with lambdas
Bugs item #1339045, was opened at 2005-10-27 02:21 Message generated for change (Settings changed) made by fijal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&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: Threads Group: Python 2.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Threading misbehavior with lambdas Initial Comment: suppose i write: def f(x): print x() for i in range(3): f ( lambda : i ) I got 0,1,2 But when I write for i in range(3): thread . start_new_thread ( f , ( lambda : i ) ) I got 2,2,2 Probably I don't get well design principles, but isn't it against thread consistency? (as long as threads does not interact with each other, interlace doesn't matter). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-27 03:08 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). -- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 19:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs
Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&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 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). -- >Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. -- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1309676 ] Add os.path.relpath
Feature Requests item #1309676, was opened at 2005-09-30 20:38 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&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 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.path.relpath Initial Comment: Add a method to os.path which calculates the "difference" of two paths. See this python-dev thread for details and sample implementations: http://mail.python.org/pipermail/python-dev/2005-September/056391.html -- Comment By: Richard Barran (rbarran) Date: 2005-10-27 20:33 Message: Logged In: YES user_id=1207189 Hi, Submitted a patch #1339796 to add this function. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1339806 ] CVS webbrowser.py (1.40) bugs
Bugs item #1339806, was opened at 2005-10-27 11:37 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=1339806&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 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339806&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1339806 ] CVS webbrowser.py (1.40) bugs
Bugs item #1339806, was opened at 2005-10-27 11:37 Message generated for change (Settings changed) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339806&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: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339806&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1338264 ] Memory keeping
Bugs item #1338264, was opened at 2005-10-26 02:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,1000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1339045 ] Threading misbehavior with lambdas
Bugs item #1339045, was opened at 2005-10-26 17:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&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: Threads Group: Python 2.4 Status: Deleted Resolution: None Priority: 5 Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Threading misbehavior with lambdas Initial Comment: suppose i write: def f(x): print x() for i in range(3): f ( lambda : i ) I got 0,1,2 But when I write for i in range(3): thread . start_new_thread ( f , ( lambda : i ) ) I got 2,2,2 Probably I don't get well design principles, but isn't it against thread consistency? (as long as threads does not interact with each other, interlace doesn't matter). -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:32 Message: Logged In: YES user_id=341410 This is a bug in your understanding of lambdas, not in how threads work. More specifically, lambdas do late binding. By the time the threads have actually started executing and call the lambda, the name 'i' is bound to the value 2. If you need early binding, then you should bind early: for i in xrange(3): thread.start_new_thread(f, (lambda i=i:i)) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint
Bugs item #1313051, was opened at 2005-10-04 09:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:38 Message: Logged In: YES user_id=341410 tony_nelson: Raising an exception during execution need not crash a user program, that's why Guido added try/except clauses into the language. You would be well advised to learn about and use them, as you will no doubt run into other exception-causing situations in the future. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-21 07:27 Message: Logged In: YES user_id=38388 This should be resolved with the new codec in CVS. -- Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 19:16 Message: Logged In: YES user_id=1356214 >Tony: Python is not damaging your data - the codec will >raise an exception in case that particular character is >converted to Unicode. Right, crashing the unsuspecting user's program and destroying the data utterly. Anyway, it doesn't damage /my/ data because I add the missing codepoint to the codec: # Fix missing Apple logo in mac_roman. import encodings.mac_roman if not encodings.mac_roman.decoding_map[0xF0]: encodings.mac_roman.decoding_map[0xF0] = 0xF8FF encodings.mac_roman.encoding_map[0xF8FF] = 0xF0 It just damages data for all the other users of the codec. >Please recreate the codec using gencodec.py (which you can >find the Tools/ directory) and add it as attachement to this >bug report. Thanks. Umm, I take it you want me to download a mapping file first. Here is a new mac_roman.py. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-04 14:48 Message: Logged In: YES user_id=38388 Tony, comment like yours are not very helpful. Python's codecs rely on facts defined by standards bodies, e.g. the Unicode consortium, ISO, etc.. If you don't present proof of your claim then there's nothing much we can do about your particular problem. Fortunately, proof isn't hard to find in this case: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT Looks like Apple added the mapping sometime after the codec was created. Walter: it is common for companies to add their logos as private Unicode characters. This happens a lot in the Asian world. Of course, interop isn't great, but at least you don't lose information by converting to Unicode. Tony: Python is not damaging your data - the codec will raise an exception in case that particular character is converted to Unicode. Please recreate the codec using gencodec.py (which you can find the Tools/ directory) and add it as attachement to this bug report. Thanks. -- Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 13:41 Message: Logged In: YES user_id=1356214 It isn't Python's job to tell people what characters they are allowed to use. Apple defined the codepoint and its mapping to Unicode. Python is not the Unicode Police, and should not damage the data it was given just to prove a point. Damaging the user's data isn't very "batteries included". -- Comment By: Walter Dörwald (doerwalter) Date: 2005-10-04 11:07 Message: Logged In: YES user_id=89016 The codepoint 0xF8FF is in the Private Use Area, so this is not an official Unicode character, and for other uses 0xF8FF might mean something completely different. So I think this mapping shouldn't be added to mac_roman. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http
[ python-Bugs-1338264 ] Memory keeping
Bugs item #1338264, was opened at 2005-10-26 05:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,1000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) -- >Comment By: Tim Peters (tim_one) Date: 2005-10-27 15:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(1000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(1000) instead will consume very little RAM. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 15:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1339883 ] TAB SETTINGS DONT WORK (win)
Bugs item #1339883, was opened at 2005-10-27 12:41 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=1339883&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.4 Status: Open Resolution: None Priority: 5 Submitted By: reson5 (reson5) Assigned to: Nobody/Anonymous (nobody) Summary: TAB SETTINGS DONT WORK (win) Initial Comment: Hi! I have downloaded newer version of Python and unfortunately the TAB settings in IDLE have no effect on the spaces inserted - ALWAYS 4 spaces. Previous release had the same problem. Win 2k, Python 2.4.2. Regards, Reson -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193099 ] Embedded python thread crashes
Bugs item #1193099, was opened at 2005-04-30 12:03
Message generated for change (Comment added) made by ugodiggi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&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: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: ugodiggi (ugodiggi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Embedded python thread crashes
Initial Comment:
The following code crashes about 1/3 of the times.
My platform is Python 2.4.1 on WXP (I tried the release
version from the msi and the debug version built by me).
I can reproduce the same behavior on another wxp
system, under python 2.4.
The crash happens (in the python thread) while the main
thread is in Py_Finalize.
I traced the crash to _Py_ForgetReference(op) in
object.c at line 1847, where I have op->_ob_prev == NULL.
The open file seems to be the issue, since if I remove
all the references to the file I cannot get the program
to crash.
Cheers and ciao
Ugo
// TestPyThreads.cpp
//
#include // Sleep
#include "Python.h"
int main()
{
PyEval_InitThreads();
Py_Initialize();
PyGILState_STATE main_restore_state =
PyGILState_UNLOCKED;
PyGILState_Release(main_restore_state);
// start the thread
{
PyGILState_STATE state =
PyGILState_Ensure();
int trash = PyRun_SimpleString(
"import thread\n"
"import time\n"
"def foo():\n"
" f =
open('pippo.out', 'w', 0)\n"
" i = 0;\n"
" while 1:\n"
"f.write('%d\n'%i)\n"
"time.sleep(0.01)\n"
"i += 1\n"
"t =
thread.start_new_thread(foo, ())\n"
);
PyGILState_Release(state);
}
// wait 300 ms
Sleep(300);
PyGILState_Ensure();
Py_Finalize();
return 0;
}
--
>Comment By: ugodiggi (ugodiggi)
Date: 2005-10-27 22:19
Message:
Logged In: YES
user_id=1269908
I'm sorry I've been so late in answering.
I don't have the time to investigate on the short term, and I'm
very unfamiliar with python internals.
I did do a fair amount of testing when I originally posted the
item, including running with the 2.4.0 and 2.4.1 downloaded
from python.org and 2.4.1 built by me in release and debug
mode. I also tried on a different windows machine, running XP
and 2.4.?.
All were showing the same problem.
I've followed the google thread and I don't think it's the same
problem.
My best guess is that this is caused by a leaked open file
handle, that does not get closed correctly in the Py_Finalize
call, but I'm not quite sure on how to follow this in the
debugger.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 20:52
Message:
Logged In: YES
user_id=33168
Perhaps this is caused by different runtime DLLs. Here's
what I googled for: site:mail.python.org windows python
runtime dll crash
See http://python.org/sf/1003535
Can you try to research more and see if you can come up with
anything? (I don't run windows, so I can't test anything.)
Do you get this problem with the version built from
python.org or only with the version you built?
--
Comment By: ugodiggi (ugodiggi)
Date: 2005-10-06 00:29
Message:
Logged In: YES
user_id=1269908
Something changed on the computer I'm testing on, and the
crash happens way less often (say 1/10 of the times in debug
mode, and very rarely in Release mode).
The compiler is MSVC7.1 on WXP, using Python 241
This is the stack of the main thread
7ffe0304()
ntdll.dll!77f5b5d4()
kernel32.dll!77e7a683()
msvcr71d.dll!_close_lk(int fh=0x0003) Line 115 +
0x4aC
msvcr71d.dll!_close(int fh=0x0003) Line 60 + 0x9
C
msvcr71d.dll!_fclose_lk(_iobuf * str=0x1027c898) Line
127 + 0xc C
msvcr71d.dll!fclose(_iobuf * stream=0x1027c898) Line
58 + 0x9C
> python24_d.dll!file_dealloc(PyFileObject *
f=0x00919ec8) Line 308 + 0xd C
python24_d.dll!_Py_Dealloc(_object * op=0x00919ec8)
Line 1870 + 0x7 C
python24_d.dll!frame_dealloc(_frame * f=0x00972960)
Line 394 + 0x67 C
python24_d.dll!_Py_Dealloc(_object * op=0x00972960)
Line 1870 + 0x7 C
[ python-Bugs-1336623 ] tarfile can't extract some tar archives..
Bugs item #1336623, was opened at 2005-10-24 10:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&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
Submitted By: A. Murat EREN (meren)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile can't extract some tar archives..
Initial Comment:
Here is a small demo to reproduce the same problem:
-8<-8<-8<-8<---
[EMAIL PROTECTED] /home/meren $ wget
ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz
(...)
100%[>] 270,953 17.13K/sETA 00:00
20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953]
[EMAIL PROTECTED] /home/meren $ file db.1.85.tar.gz
db.1.85.tar.gz: gzip compressed data, from Unix
[EMAIL PROTECTED] /home/meren $ python
>>> tar = tarfile.open("db.1.85.tar.gz", "r:gz")
>>> for tarinfo in tar:
... print tarinfo.name
...
db.1.85
db.1.85/btree
db.1.85/btree/Makefile.inc
db.1.85/btree/bt_close.c
db.1.85/btree/bt_conv.c
db.1.85/btree/bt_debug.c
db.1.85/btree/bt_delete.c
db.1.85/btree/btree.h
db.1.85/btree/bt_get.c
db.1.85/btree/bt_open.c
(...)
>>> for tarinfo in tar:
... tar.extract(tarinfo)
...
>>> Ctrl + D
[EMAIL PROTECTED] /home/meren $ ls db*
db.1.85
db.1.85.tar.gz
[EMAIL PROTECTED] /home/meren $ file db.1.85
db.1.85: empty
[EMAIL PROTECTED] /home/meren $ cat db.1.85
[EMAIL PROTECTED] /home/meren $
->8->8->8->8---
Also this file is extracting with the same result too:
ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz
This thing is very rarely happening, but it is
happening. Also, I could extract these archives
properly via the native 'tar' binary..
Thanks in advance,
Ciao.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-27 23:01
Message:
Logged In: YES
user_id=33168
Committed revision 41340.
Committed revision 41341.
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-26 05:35
Message:
Logged In: YES
user_id=718263
thanks for the patch, it is just working.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2005-10-26 03:31
Message:
Logged In: YES
user_id=642936
I submitted patch #1338314 which fixes this problem.
tarfile.py is aware of these "buggy" archives, but the
workaround did not work anymore.
Thank you for your report, especially for the vast number of
test archives.
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-25 11:58
Message:
Logged In: YES
user_id=718263
no files attached.. sorry, here it is..
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-25 11:36
Message:
Logged In: YES
user_id=718263
I figured out that this is a very pesky problem.
The problem is coming from the tar archives themselves.
Simply, the "tarinfo.isdir()" check in the library returns
false for the directories and they are extracting like a
regular file.. How did they create these fool archives I
don't know, and I couldn't reproduce similar buggy archives
by myself. It would be nice to know.
Because of the problem is not in the python library, it is
very difficult to implement an efficent workaround to
properly extract this kind of buggy tar archives. I'm going
to attach a dirty workaround to show the idea (is anyone
reading these reports?)..
Ciao..
--
Comment By: A. Murat EREN (meren)
Date: 2005-10-24 11:19
Message:
Logged In: YES
user_id=718263
more examples:
ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
additionally, the same problem appearing when trying to extract
these archives with the "ark" (yet another kde tool, just a simple
front-end for the tar command. interesting, isn't it).
Ciao.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1340337 ] time.strptime() with bad % code throws bad exception
Bugs item #1340337, was opened at 2005-10-27 23:48 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=1340337&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steve R. Hastings (steveha) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() with bad % code throws bad exception Initial Comment: I am using Python 2.4.2, the latest version currently available for the system I am using, which is Ubuntu 5.10 for x86. I was calling the time.strptime() function, and I had accidentally typed an extra % symbol in the time format string. If you do this you get a baffling message in the traceback. The deepest frame of the traceback looks like this: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '-' This means that I accidentally put "%-" in my format string. What happens if I accidentally put "% " in my format string? This: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '\' It turns out that spaces in the format string are replaced by r'\s*' by the time the exception happens. It really freaked me out to see Python complaining about a backslash, when I hadn't put a backslash into my format string. I propose that this library call should be re-written to catch the exception, and then throw a more sensible exception, including a statement like: "unknown % code in format string". In a perfect world this would be done in such a way that the last frame appearing in the traceback would be for the call to time.strptime(), and not show any lines from the guts of time.strptime() about regular expression compiling. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1340337&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
