[issue3039] tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError
New submission from Jason Kankiewicz <[EMAIL PROTECTED]>:
tarfile.TarFileCompat.writestr( self, zinfo, bytes ) raises
AttributeError("'ZipInfo' object has no attribute 'name'") because an
analog to the tarfile.TarInfo.name attribute cannot be monkeypatched
into the zinfo argument value when it's an instance of zipfile.ZipInfo.
The zipfile.ZipInfo class' attributes are slots, so no ad hoc attributes
can be monkeypatched into an instance of it.
I've replaced the monkeypatching of zinfo with the creation of a new
tarfile.TarInfo object, tinfo, which receives its relevant values instead.
This revealed another problem with the assignment of zinfo.file_size to
tinfo.size: if zinfo.file_size has not been assigned a value then an
AttributeError("file_size") will be raised because the slotted attribute
doesn't exist.
Being that the documentation for zipfile.ZipFile.writestr( self,
zinfo_or_arcname, bytes ) claims that a zipfile.ZipInfo object value for
zinfo_or_arcname must contain "at least the filename, date and time",
it's highly likely that zinfo.file_size will be unassigned in ordinary use.
I fixed this problem by ignoring the value of zinfo.file_size and using
the value of len(bytes) instead, just like the implementation of
zipfile.ZipFile.writestr.
I would have provided a patch for tarfile.TarFileCompat.writestr's unit
test suite, but it doesn't appear to exist.
--
components: Library (Lib)
files: tarfile.TarFileCompat.patch
keywords: patch
messages: 67708
nosy: jkankiewicz
severity: normal
status: open
title: tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10520/tarfile.TarFileCompat.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3039>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4827] optparse: Callback example 1 is confusing
New submission from Jason Kankiewicz :
"Callback example 1: trivial callback" reads
Here’s an example of a callback option that takes no arguments, and
simply records that the option was seen:
def record_foo_seen(option, opt_str, value, parser):
parser.saw_foo = True
parser.add_option("--foo", action="callback",
callback=record_foo_seen)
but the following paragraph
Of course, you could do that with the store_true action.
is wrong because
parser.add_option("--foo", action="store_true", dest="saw_foo")
would actually be duplicated by
def record_foo_seen(option, opt_str, value, parser):
parser.values.saw_foo = True
parser.add_option("--foo", action="callback",
callback=record_foo_seen)
For example:
>>> from optparse import OptionParser
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
... parser.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
>>> parser.parse_args(['--foo'])
(, [])
>>> parser = OptionParser()
>>> parser.add_option("--foo", action="store_true", dest="saw_foo")
>>> parser.parse_args(['--foo'])
(, [])
>>> parser = OptionParser()
>>> def record_foo_seen(option, opt_str, value, parser):
... parser.values.saw_foo = True
...
>>> parser.add_option("--foo", action="callback", callback=record_foo_seen)
>>> parser.parse_args(['--foo'])
(, [])
--
assignee: georg.brandl
components: Documentation
messages: 79039
nosy: georg.brandl, jkankiewicz
severity: normal
status: open
title: optparse: Callback example 1 is confusing
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue4827>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1254718] GCC detection for runtime_library_dirs when ccache is used
Jason Kankiewicz added the comment: I've attached a patch, based on the original, that will fix distutils for both GCC and ICC. -- nosy: +jkankiewicz Added file: http://bugs.python.org/file14250/distutils-rpath-gcc_and_icc.patch ___ Python tracker <http://bugs.python.org/issue1254718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1254718] GCC detection for runtime_library_dirs when ccache is used
Changes by Jason Kankiewicz : Removed file: http://bugs.python.org/file14250/distutils-rpath-gcc_and_icc.patch ___ Python tracker <http://bugs.python.org/issue1254718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1254718] GCC detection for runtime_library_dirs when ccache is used
Jason Kankiewicz added the comment: I've updated my patch to resemble the patch from issue1032 and also because profiling showed that using str.__contains__ is more efficient than using str.find. -- Added file: http://bugs.python.org/file14251/distutils-rpath-gcc_and_icc.patch ___ Python tracker <http://bugs.python.org/issue1254718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1254718] GCC detection for runtime_library_dirs when ccache is used
Jason Kankiewicz added the comment: Seo, This ticket specifies Python-2.6 as the only version so using "any" didn't seem to be a problem. I was not aware of PEP 291 until you mentioned it and, in order to maintain compatibility with Python-2.3, the generator expression would have to be dispensed with as well. Raymond, I would prefer to substitute "max" for "any" in this case as it seems to be more straightforward. There's no performance benefit to using "min" as both "min" and "max" are O(n), no? -- Added file: http://bugs.python.org/file14261/distutils-rpath-gcc_and_icc.patch ___ Python tracker <http://bugs.python.org/issue1254718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
