[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Armin Rigo (arigo) Date: 2005-09-25 08:55 Message: Logged In: YES user_id=4771 The bug is related to code like PyObject_GenericGetAttribute and _PyType_Lookup which are not careful about the reference counters of the objects they operate on. This allows a much simpler crash (test67.py): the __dict__ of an object can be decrefed away while lookdict() is looking at it. This has a simple fix -- drop some amount of Py_INCREF/Py_DECREF in core routines like PyObject_GenericGetAttr. We probably need to measure if it has a performance impact, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295909 ] inspect.getsource() misses single line blocks.
Bugs item #1295909, was opened at 2005-09-20 01:00
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&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: Ron Adam (ronadam)
>Assigned to: Armin Rigo (arigo)
>Summary: inspect.getsource() misses single line blocks.
Initial Comment:
While playing around with the inspect module I found
that the Blockfinder doesn't recognize single line
function definitions.
Adding the following two lines to it fixes it, but I'm
not sure if it causes problems anywhere else.
C:\Python24\Lib>diff.py inspect.py inspect_.py
*** inspect.py Tue Mar 15 13:22:02 2005
--- inspect_.py Mon Sep 19 14:26:26 2005
***
*** 531,536
--- 531,538
raise EndOfBlock, self.last
elif type == tokenize.NAME and scol == 0:
raise EndOfBlock, self.last
+ elif self.indent == 0:
+ raise EndOfBlock, self.last
def getblock(lines):
"""Extract the block of code at the top of the
given list of lines."""
Version info:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
def test(t):
print '**',t,'**'
print "Line:"
def f(): pass
""" This line shouldn't be visible """
print inspect.getsource(f)
print "Block:"
def f():
pass
pass
"""This line should not be visible."""
print inspect.getsource(f)
import inspect
test("before")
import inspect_ as inspect
test("after")
#-- output --
** before **
Line:
def f(): pass
""" This line shouldn't be visible """
print inspect.getsource(f)
print "Block:"
def f():
pass
pass
Block:
def f():
pass
pass
** after **
Line:
def f(): pass
Block:
def f():
pass
pass
--
>Comment By: Armin Rigo (arigo)
Date: 2005-09-25 10:57
Message:
Logged In: YES
user_id=4771
While working on PyPy we stubled over a couple of bugs in getsource() as well,
and thought about some fix. I will add your example and a few more to
test_inspect.py and fix/clean up a bit getblock() in inspect.py. I will also
try to stress-test getsource() on some example programs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI
Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Comment added) made by matthewleslie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. -- >Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 11:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 04:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295909 ] inspect.getsource() misses single line blocks.
Bugs item #1295909, was opened at 2005-09-20 01:00
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ron Adam (ronadam)
Assigned to: Armin Rigo (arigo)
Summary: inspect.getsource() misses single line blocks.
Initial Comment:
While playing around with the inspect module I found
that the Blockfinder doesn't recognize single line
function definitions.
Adding the following two lines to it fixes it, but I'm
not sure if it causes problems anywhere else.
C:\Python24\Lib>diff.py inspect.py inspect_.py
*** inspect.py Tue Mar 15 13:22:02 2005
--- inspect_.py Mon Sep 19 14:26:26 2005
***
*** 531,536
--- 531,538
raise EndOfBlock, self.last
elif type == tokenize.NAME and scol == 0:
raise EndOfBlock, self.last
+ elif self.indent == 0:
+ raise EndOfBlock, self.last
def getblock(lines):
"""Extract the block of code at the top of the
given list of lines."""
Version info:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
def test(t):
print '**',t,'**'
print "Line:"
def f(): pass
""" This line shouldn't be visible """
print inspect.getsource(f)
print "Block:"
def f():
pass
pass
"""This line should not be visible."""
print inspect.getsource(f)
import inspect
test("before")
import inspect_ as inspect
test("after")
#-- output --
** before **
Line:
def f(): pass
""" This line shouldn't be visible """
print inspect.getsource(f)
print "Block:"
def f():
pass
pass
Block:
def f():
pass
pass
** after **
Line:
def f(): pass
Block:
def f():
pass
pass
--
>Comment By: Armin Rigo (arigo)
Date: 2005-09-25 11:51
Message:
Logged In: YES
user_id=4771
Checked in:
Lib/inspect.py 1.63
Lib/test/inspect_fodder2.py 1.5
Lib/test/test_inspect.py 1.21
Not backported to 2.4 for now (the branch is frozen for 2.4.2 release and it's
unclear if this is critical enough).
Thanks! The patch I applied is essentially what you proposed, with the
exception of special tokens (NL and COMMENT) that should not end a block even
at indentation level zero.
--
Comment By: Armin Rigo (arigo)
Date: 2005-09-25 10:57
Message:
Logged In: YES
user_id=4771
While working on PyPy we stubled over a couple of bugs in getsource() as well,
and thought about some fix. I will add your example and a few more to
test_inspect.py and fix/clean up a bit getblock() in inspect.py. I will also
try to stress-test getsource() on some example programs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295909&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303928 ] Extended slice bug (or feature?)
Bugs item #1303928, was opened at 2005-09-25 13:06 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=1303928&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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5]# b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1]# d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303928 ] Extended slice bug (or feature?)
Bugs item #1303928, was opened at 2005-09-25 15:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&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: Closed >Resolution: Invalid Priority: 5 Submitted By: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5]# b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1]# d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 15:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303928 ] Extended slice bug (or feature?)
Bugs item #1303928, was opened at 2005-09-25 14:06 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&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: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5]# b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1]# d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave -- >Comment By: Michael Hudson (mwh) Date: 2005-09-25 14:17 Message: Logged In: YES user_id=6656 Yes, it's intended. l[i:j:k][0] == l[i] when it makes sense, and the sense of omitted indices flips depending on the sign of k. It's a bit confusing, but then I think all the variants are in some cases. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 14:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303928 ] Extended slice bug (or feature?)
Bugs item #1303928, was opened at 2005-09-25 15:06 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&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: Closed >Resolution: Invalid Priority: 5 Submitted By: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5]# b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1]# d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 15:25 Message: Logged In: YES user_id=1188172 Closing again ;) -- Comment By: Michael Hudson (mwh) Date: 2005-09-25 15:17 Message: Logged In: YES user_id=6656 Yes, it's intended. l[i:j:k][0] == l[i] when it makes sense, and the sense of omitted indices flips depending on the sign of k. It's a bit confusing, but then I think all the variants are in some cases. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 15:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303928 ] Extended slice bug (or feature?)
Bugs item #1303928, was opened at 2005-09-25 13:06 Message generated for change (Comment added) made by beazley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&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: Closed Resolution: Invalid Priority: 5 Submitted By: David M. Beazley (beazley) Assigned to: Nobody/Anonymous (nobody) Summary: Extended slice bug (or feature?) Initial Comment: Consider a sequence: a = [1,2,3,4,5,6,7,8,9,10] Now, consider the following slices: b = a[:-5]# b gets [1,2,3,4,5] c = a[:-5:1] # c gets [1,2,3,4,5] d = a[:-5:-1]# d gets [10,9,8,7] Is this the intended behavior?? I would have suspected the value of d to be [5,4,3,2,1] (the same elements of c, but in reverse order). Thanks. -- Dave -- >Comment By: David M. Beazley (beazley) Date: 2005-09-25 15:50 Message: Logged In: YES user_id=7557 Thanks for the clarificationjust making sure I get this absolutely right before committing anything to paper here. -- Dave. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 13:25 Message: Logged In: YES user_id=1188172 Closing again ;) -- Comment By: Michael Hudson (mwh) Date: 2005-09-25 13:17 Message: Logged In: YES user_id=6656 Yes, it's intended. l[i:j:k][0] == l[i] when it makes sense, and the sense of omitted indices flips depending on the sign of k. It's a bit confusing, but then I think all the variants are in some cases. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 13:16 Message: Logged In: YES user_id=1188172 No. With a step of -1, the slice always starts at the end (at 10). The stop (that is 6, in this case) is never included, and so you get your result. If you want [5,4,3,2,1], use a[:-5][::-1] or reversed(a[:-5]). PS: comp.lang.python is a better place to discuss whether something is really a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1304179 ] 2.3.5 configure / make infinite loop
Bugs item #1304179, was opened at 2005-09-25 15:49 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=1304179&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: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Schwartz (nynymike) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 configure / make infinite loop Initial Comment: I am trying to install python 2.3.5 from source on FC4 to /usr/local. # ./configure --prefix=/usr/local works ok. But when I do # make I get caught in an infinite loop where it just runs the configure script over and over. Thanks! - Mike -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1304179&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-467924 ] Improve the ZipFile Interface
Feature Requests item #467924, was opened at 2001-10-04 15:54 Message generated for change (Comment added) made by scott_daniels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. -- Comment By: Scott David Daniels (scott_daniels) Date: 2005-09-25 20:20 Message: Logged In: YES user_id=493818 I am currently working on an expanded zipfile module that: (a) Has a more easily extensible class (b) Allows BZIP2 compression (my orginal need) (c) Allows file-like (read) access to the elements of ZipFile (d) Provides for a single "writer" which can be used to generate file contents "incrementally" while possibly reading from other "files" in the zipfile (e) Allows the opening of embedded zips "in-place" What I don't have at the moment is a good set of tests or good documents of how to use it. Anyone interested in collaborating, let me know. --Scott David Daniels -- Comment By: Chuck Rhode (crhode) Date: 2005-09-22 15:56 Message: Logged In: YES user_id=988879 I've been trying to read map files put out by the Census Bureau. These ZIP archives are downloaded from government contractors' sites by county. Within each county archive are several ZIP files for each map layer (roads, streams, waterbodies, etc). Each contains the elements of an ESRI shapefile database (.shp, .shx., and .dbf files). This doesn't make a lot of sense to me, either, because there's no compression advantage to making an archive of an archive. The technique is used purely for organizational purposes because ZIP does not compress subdirectories. Note: I've never seen a TAR of TAR files because TAR *does* compress subdirectories. What I've been struggling with is a way to leave these archives in their compressed form and still do *python* I/O on them. There is a tree organization to them, after all, just as with traditional os.path directories. I've designed some objects that let me retrieve the most recent file, ZIP member, or TAR member by name from a given path to a repository of such archives. What I get is a StreamIO object that I can subsequently put back where it came from. What would be nice is if there already were objects available to manipulate normal os.path directories comingled with ZIP and TAR archives. What would be nicer is if I/O could be opened at the character/line level transparently without regard to whether the source/destination was a file or an archive member within such a structure. In the days of hardware compression and on-the-fly encryption/decryption of I/O, is this too much to ask? -ccr- -- Comment By: Myers Carpenter (myers_carpenter) Date: 2004-05-09
[ python-Bugs-1304179 ] 2.3.5 configure / make infinite loop
Bugs item #1304179, was opened at 2005-09-25 21:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1304179&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: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Schwartz (nynymike) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 configure / make infinite loop Initial Comment: I am trying to install python 2.3.5 from source on FC4 to /usr/local. # ./configure --prefix=/usr/local works ok. But when I do # make I get caught in an infinite loop where it just runs the configure script over and over. Thanks! - Mike -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-25 22:29 Message: Logged In: YES user_id=1188172 Not that I want to say that you don't have a problem, but if you are installing from source anyway, couldn't you try 2.4.1 (or the upcoming 2.4.2)? Moreover it's not likely that there will be a 2.3.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1304179&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-467924 ] Improve the ZipFile Interface
Feature Requests item #467924, was opened at 2001-10-04 10:54 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=467924&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. -- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2005-09-25 18:29 Message: Logged In: YES user_id=1115903 Scott, I had put together some enhancements to ZipFile read/write, including test cases, but haven't had time to advocate getting it into 2.5. You can find it here: https://sourceforge.net/tracker/?func=detail&aid=1121142&group_id=5470&atid=305470 If it seems like it would be helpful, I can go round up the most recent version (that I've been using in a production environment) and send it to you. -- Comment By: Scott David Daniels (scott_daniels) Date: 2005-09-25 15:20 Message: Logged In: YES user_id=493818 I am currently working on an expanded zipfile module that: (a) Has a more easily extensible class (b) Allows BZIP2 compression (my orginal need) (c) Allows file-like (read) access to the elements of ZipFile (d) Provides for a single "writer" which can be used to generate file contents "incrementally" while possibly reading from other "files" in the zipfile (e) Allows the opening of embedded zips "in-place" What I don't have at the moment is a good set of tests or good documents of how to use it. Anyone interested in collaborating, let me know. --Scott David Daniels -- Comment By: Chuck Rhode (crhode) Date: 2005-09-22 10:56 Message: Logged In: YES user_id=988879 I've been trying to read map files put out by the Census Bureau. These ZIP archives are downloaded from government contractors' sites by county. Within each county archive are several ZIP files for each map layer (roads, streams, waterbodies, etc). Each contains the elements of an ESRI shapefile database (.shp, .shx., and .dbf files). This doesn't make a lot of sense to me, either, because there's no compression advantage to making an archive of an archive. The technique is used purely for organizational purposes because ZIP does not compress subdirectories. Note: I've never seen a TAR of TAR files because TAR *does* compress subdirectories. What I've been struggling with is a way to leave these archives in their compressed form and still do *python* I/O on them. There is a tree organization to them, after all, just as with traditional os.path directories. I've designed some objects that let me retrieve the most recent file, ZIP member, or TAR member by name from a given path to a repository of such archives. What I get is a StreamIO object that I can subsequently put back where it came fr
