[issue15795] Zipfile.extractall does not preserve file permissions
Karen Tracey added the comment: Note the zipfile being processed may have been created on a non-Unix system, and the external_attr value can't be usefully interpreted as permission bits when the value at _CD_CREATE_SYSTEM (https://hg.python.org/cpython/file/default/Lib/zipfile.py#l107) in the central directory entry is not Unix (3). Patches so far don't seem to guard against mistakenly assuming a foreign-system external_attr value can be interpreted as Unix permission bits. (At present github is delivering zipfiles of repos with a create system value of 0 and external_attr values of 0.) -- nosy: +kmtracey ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8400] zipimporter find_module fullname mis-documented
New submission from Karen Tracey kmtra...@gmail.com:
The fullname parameter to zipimporter find_module is documented to be a fully
qualified (dotted) module name. (From
http://docs.python.org/library/zipimport.html#zipimport.zipimporter.find_module.)
However, passing a fully-qualified dotted module appears to never work. Rather
it appears that you must use the file system path separator instead of dots.
For example on Windows:
C:\echo %pythonpath%
\tmp\blah-1.0-py2.6.egg
C:\python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
from blah.models import speak
speak.__file__
'C:\\tmp\\blah-1.0-py2.6.egg\\blah\\models\\speak.pyc'
speak.sayhi()
Hi from blah.models.speak sayhi function.
The egg has top-level blah package and under it models, it appears to work fine
for normal use. But zipimport zipimporter find_module won't find the models
sub-module using dotted path notation:
import sys
sys.path[1]
'C:\\tmp\\blah-1.0-py2.6.egg'
import zipimport
zi = zipimport.zipimporter(sys.path[1])
zi.find_module('blah')
zipimporter object C:\tmp\blah-1.0-py2.6.egg
zi.find_module('blah.models')
zi.find_module('blah/models')
zi.find_module('blah\\models')
zipimporter object C:\tmp\blah-1.0-py2.6.egg
On Linux, the 'blah/models' version is the one that works.
Tested as far back as Python2.3 and as far forward as 2.7a3.
--
messages: 103132
nosy: kmtracey
severity: normal
status: open
title: zipimporter find_module fullname mis-documented
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8400
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3745] _sha256 et al. encode to UTF-8 by default
Karen Tracey kmtra...@gmail.com added the comment: I think the missing issue reference is to this thread on python-dev: http://mail.python.org/pipermail/python-dev/2009-December/094574.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3745] _sha256 et al. encode to UTF-8 by default
Changes by Karen Tracey kmtra...@gmail.com: -- nosy: +kmtracey ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2811] doctest doesn't treat unicode literals as specified by the file declared encoding
Karen Tracey [EMAIL PROTECTED] added the comment:
I believe the problem is in your test file, not doctest. The enclosing
doctest string is not specified as a unicode literal, so the file
encoding specification ultimately has no effect on it. At least that is
how I read the documentation regarding the effect of the ecoding
declaration (The encoding is used for all lexical analysis, in
particular to find the end of a string, and to interpret the contents of
Unicode literals. String literals are converted to Unicode for
syntactical analysis, then converted back to their original encoding
before interpretation starts.)
If you change the test file so that the string enclosing the test is a
unicode literal then the test passes:
[EMAIL PROTECTED]:~/tmp$ cat test_iso-8859-15.py
# -*- coding: utf-8 -*-
import doctest
def normalize(s):
u
normalize(u'á')
u'b'
return s.translate({ord(u'á'): u'b'})
doctest.testmod()
print 'without doctest ===', normalize(u'á')
[EMAIL PROTECTED]:~/tmp$ python test_iso-8859-15.py
without doctest === b
-
There is a problem with this, though: doctest now will be unable to
correctly report errors when there are output mismatches involving
unicode strings with non-ASCII chars. For example if you add an 'x' to
the front of your unicode literal to be normalized you'll get this when
you try to run it:
[EMAIL PROTECTED]:~/tmp$ python test_iso-8859-15.py
Traceback (most recent call last):
File test_iso-8859-15.py, line 12, in module
doctest.testmod()
File /usr/lib/python2.5/doctest.py, line 1799, in testmod
runner.run(test)
File /usr/lib/python2.5/doctest.py, line 1345, in run
return self.__run(test, compileflags, out)
File /usr/lib/python2.5/doctest.py, line 1261, in __run
self.report_failure(out, test, example, got)
File /usr/lib/python2.5/doctest.py, line 1125, in report_failure
self._checker.output_difference(example, got, self.optionflags))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in
position 149: ordinal not in range(128)
[EMAIL PROTECTED]:~/tmp$
This issue is reported in #1293741, but there is no fix or guidance
offered there on how to work around the problem.
I'd appreciate feedback on whether what I've said here is correct. I'm
currently trying to diagnose/fix problems with use of unicode literals
in some tests and this is as far as I've got. That is, I think I need to
be specifying the enclosing strings as unicode literals, but then I run
into #1293741. If the conclusion I've reached is correct, then trying
to figure out a fix for that problem should be where I focus my efforts.
If, however, I shouldn't be specifying the enclosing string as a
unicode literal, then attempting to fix the problem as described here
would perhaps be more useful. Though I do not know how the doctest code
can know the file's encoding specification?
--
nosy: +kmtracey
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2811
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Karen Tracey [EMAIL PROTECTED] added the comment: Cool, thanks! Do I take it from the Versions setting that the fix will be available in the next 2.6 beta but not get propagated to prior releases? (I'm not very familiar with this issue tracker so am just trying to understand what the various fields mean.) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Karen Tracey [EMAIL PROTECTED] added the comment: I just stumbled on this bug, it is still a problem in 2.5 and 2.6. I tried the supplied patch on 2.6b2 and it works. Before the patch: Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. ustr = u'¿Cómo' print ustr ¿Cómo import code code.interact() Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. (InteractiveConsole) ustr = u'¿Cómo' print ustr ¿Cómo After the patch: Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. ustr = u'¿Cómo' print ustr ¿Cómo import code code.interact() Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. (InteractiveConsole) ustr = u'¿Cómo' print ustr ¿Cómo I realize it's a pretty little problem, but it was quite puzzling to track down, because naturally I wasn't doing that exactly but rather using a tool that under the covers was using code.interact() and mostly behaves just like a bare python prompt except it was mangling unicode string literals. Any chance the fix could get in the code base? The last comment makes it sound like the patch was missing at one point. It's there now. Is there any concern about it breaking something? -- nosy: +kmtracey versions: +Python 2.4, Python 2.5, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1288615] Python code.interact() and UTF-8 locale
Karen Tracey [EMAIL PROTECTED] added the comment: FWIW I also tried the fix on a Windows box with Python 2.5.1. The failure there is different since the Windows command prompt apparently uses cp437 as its encoding: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. ustr = u'¿Cómo' ustr u'\xbfC\xf3mo' print ustr ¿Cómo import code code.interact() Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. (InteractiveConsole) ustr = u'¿Cómo' print ustr Traceback (most recent call last): File console, line 1, in module File d:\bin\Python2.5.1\lib\encodings\cp437.py, line 12, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeEncodeError: 'charmap' codec can't encode character u'\xa8' in position 0: character maps to undefined Applying the patch resulted in correct behavior on Windows as well. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1288615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1242657] list(obj) can swallow KeyboardInterrupt
Karen Tracey [EMAIL PROTECTED] added the comment: This behavior has reappeared in the 2.6 beta releases: Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print 'len called, raising KeyboardInterrupt' ... raise KeyboardInterrupt ... f = F() list(f) len called, raising KeyboardInterrupt [23] Should a new bug be opened for this? (I can't find one but I'm not too experienced searchign Python's bug tracker.) -- nosy: +kmtracey ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1242657 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1242657] list(obj) can swallow KeyboardInterrupt
Karen Tracey [EMAIL PROTECTED] added the comment: Thanks for responding. It had been fixed. 2.4/2.5 behave like so: Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type help, copyright, credits or license for more information. class F(object): ... def __iter__(self): ... yield 23 ... def __len__(self): ... print 'len called, raising KeyboardInterrupt' ... raise KeyboardInterrupt ... f = F() list(f) len called, raising KeyboardInterrupt Traceback (most recent call last): File stdin, line 1, in module File stdin, line 6, in __len__ KeyboardInterrupt It just seems to have regressed in 2.6. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1242657 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192
Karen Tracey [EMAIL PROTECTED] added the comment: Opening the file in universal newline mode doesn't work for cases where the 'file' contains multipart MIME data (eg. multipart/form-data) where one of the included parts is binary data (eg. application/octet-stream). In that case, blind translation of CRLF to LF may corrupt the binary data. (Thanks to Thomas Guettler for pointing that out to me.) FeedParser goes to considerable trouble to split on any conceivable line boundary but retain whatever line boundary existed in the stream when putting things back together. (Look at BufferedSubFile's push() code in feedparser.py.) It was not written on the assumption that it would be getting LFs only. The only code that knows enough to know which CRLFs are really line breaks is the code that is breaking the stream up based on the boundary markers -- that is the FeedParser code. It isn't safe for the caller to do any CRLF conversions before calling the Parser. Therefore I believe the fix needs to be made to the parser.py code, not the docs. Two people that I know of independently re-discovered this bug in the last couple of weeks (running Django), after I re-discovered it about three months ago after Jeremy Dunck re-discovered it a year earlier, three months after it was originally opened. Maybe a corner case, but it would be nice, since it is quite difficult for people to track down, and the fix is so trivial, if the fix could be put in. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue170 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192
Changes by Karen Tracey: -- nosy: +kmtracey _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue170 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
