[issue26018] documentation of ZipFile file name encoding
New submission from Martin von Gagern: https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.write writes: “Note: There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write(). WinZip interprets all file names as encoded in CP437, also known as DOS Latin.” I think this is wrong in many ways. Firstly, APPNOTE.TXT used to explicitely define CP437 as the standard, and it's still the standard in the absence of general purpose bit 11 and a more specific description using the 0x0008 Extra Field. On the other hand, we do have that general purpose bit these days, so there are now not just one but two well-defined file name encodings. And thirdly, encoding the string to bytes as suggested will in fact lead to a run time error, since ZipInfo expects to do this conversion itself. See work towards issue1734346, starting at commit 8e33f316ce14, for details on when this was addressed in the source code. -- assignee: docs@python components: Documentation messages: 257567 nosy: docs@python, gagern priority: normal severity: normal status: open title: documentation of ZipFile file name encoding type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11218] pattern=None when following documentation for load_tests and unittest.main()
Martin von Gagern martin.vgag...@gmx.net added the comment: I'm attaching a patch to better explain what I'm suggesting. As you can see, this patch doesn't change the signature of discover, nor does it change the semantics for any code that doesn't pass pattern, or that passes some pattern other than None. The only change is that now, passing pattern=None is the same as not passing pattern at all. As a result, load_tests might now pass pattern=pattern as the documentation suggests, and still be called with pattern=None without raising an exception. -- keywords: +patch Added file: http://bugs.python.org/file25208/issue11218_patternNone.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11218] pattern=None when following documentation for load_tests and unittest.main()
Martin von Gagern martin.vgag...@gmx.net added the comment: Michael wrote: […] the real pattern being passed in. I wonder, what would be the real pattern? In the code I originally pasted, the load_tests function would be invoked by loadTestsFromModule (for module __main__). There is nothing file-based about this, so although you could pass a default pattern, it wouldn't be any more or less real than passing None. It might be more useful, though. most patterns will actually *prevent* __init__.py from being loaded by test discovery - this turns out to not be very useful and in all practical cases this argument will be None. Not sure I follow there. For the root of the test suite, yes, it will always be None. But for child packages it will be the pattern that led to the discovery of the __init__.py of that package. In all practical cases this will be a string different from both None and the default of 'test*.py', as it has to match the directory name. Most likely it will be what the load_tests function of the parent package passed to its invocation of discover. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11218] pattern=None when following documentation for load_tests and unittest.main()
Martin von Gagern martin.vgag...@gmx.net added the comment: Rik, I don't follow your argument on not changing discover. Currently, if code calls discover with pattern=None, there will be an exception. So there cannot be any working code out there which passes pattern=None. Therefore, it should be all right for the implementation to detect the None and replace it by a default. No currently working code should be affected, and new code could be shorter that way. The pattern still wouldn't be stored inside the loader, so the doc there still holds. Only the fallback for None would be stored. By the way, what's the rationale behind passing the pattern to the load_tests function? Shouldn't each package decide which of its files constitute the test suite, independent of what the parent module used as a filter? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin von Gagern martin.vgag...@gmx.net added the comment:
As people keep stating how easy the change from sys.platform == 'linux2' to
sys.platform.startswith('linux') is, e.g. msg142385, please also keep in mind
cases like someDict.get(sys.platform) where the comparison is implicit and
therefore a simple change to startswith won't do the trick. Seen that in the
wild.
Besides that, I can only wholeheartedly agree to the points so eloquently
described by Martin v. Löwis and James Y Knight. Thanks!
Let's please force it to 'linux2' for the next 2.7 and 3.2 releases, so people
can use recent kernels without breaking (or having to rewrite) third-party
apps. Let's also encourage distros to do the same for older releases, perhaps
even suggesting patches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12326
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin von Gagern martin.vgag...@gmx.net added the comment: Marc-Andre Lemburg wrote: Both Python and the application will make certain assumptions about the platform depending on the compile time environment. Can you give examples for this? So you need both the compile and the runtime version information. I very much doubt that any feature in Python is actually enabled if compiled under Linux 3. If so that's probably a bug in Python, due to the small number of features added from 2.6.39 to 3.0. Either the feature was introduced into Linux before 3.0, in which case Python should use it as early as possible, or the feature was introduced in some 3.x release, in which case not all Linux 3 builds will have it. So the single digit major number will not be enough for this kind of checks, and the safest way is to check for the feature itself, e.g. by simply using it and handling NotImplementedException appropriately. That approach is more portable for new platforms as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12719] Direct access to tp_dict can lead to stale attributes
New submission from Martin von Gagern martin.vgag...@gmx.net: The attached C extension provides a way to manually set an element in the dict of an extension type. As the test case exposes, this can result in a discrepancy between cls.__dict__['key'] and cls.key. Please tell me up front if my extension simply does something explixitely forbidden, and point me at the documentation saying so. http://docs.python.org/py3k/c-api/typeobj.html#PyTypeObject.tp_dict at least doesn't appear to explicitely forbid my approach, even if it probably is not the preferred way. If you consider what I'm doing to be really evil, you might want to ban that practice more clearly, by adding a suitable note to the documentation of the tp_dict member. In case you cannot reproduce, running the attached testcase script with test as its sole command line argument, I get the following lines, among others: Traceback (most recent call last): File .../setDictTest.py, line 10, in test1 self.assertEqual(setDictCls.__dict__['key'], setDictCls.key) AssertionError: 'bar' != 'foo' I assume that the attribute-style setDictCls.key access will somehow cache its result, thus missing the modification to the underlying dict. Just a guess, though. I've had this issue involved in segmentation faults, where the stale object had already been finalized. But as the code involved there might have been broken in other ways as well, I'll not classify this as type crash but only as behaviour. -- components: Extension Modules files: setup.py messages: 141840 nosy: gagern priority: normal severity: normal status: open title: Direct access to tp_dict can lead to stale attributes type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file22868/setup.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12719 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Martin von Gagern martin.vgag...@gmx.net: -- nosy: +gagern ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12695] subprocess.Popen: OSError: [Errno 9] Bad file descriptor
New submission from Martin von Gagern martin.vgag...@gmx.net: suprocess.Popen on POSIX (using _posixsubprocess Module) has a good chance of repeatedly closing the same file descriptor if the descriptor for stdin is also used for stdout and/or stderr. Only stdout and stderr are checked for equality with one another. This breaks webbrowser.open for me, as the browser remote has all three descriptors redirected from/to /dev/null. This breaks pydoc -p. I've taken this scenario and turned it into a unit test, which you find attached together with a proposed fix. On my currently installed Python 3.2, the unit tests results in this traceback (and two more like it for other test classes): ERROR: test_inouterr_fileobj (__main__.ProcessTestCase) -- Traceback (most recent call last): File Lib/test/test_subprocess.py, line 630, in test_inouterr_fileobj stderr = devnull) File /usr/lib64/python3.2/subprocess.py, line 736, in __init__ restore_signals, start_new_session) File /usr/lib64/python3.2/subprocess.py, line 1330, in _execute_child raise child_exception_type(errno_num, err_msg) OSError: [Errno 9] Bad file descriptor -- components: Library (Lib) files: subprocess.patch keywords: patch messages: 141653 nosy: gagern priority: normal severity: normal status: open title: subprocess.Popen: OSError: [Errno 9] Bad file descriptor type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file22836/subprocess.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12695] subprocess.Popen: OSError: [Errno 9] Bad file descriptor
Martin von Gagern martin.vgag...@gmx.net added the comment: Sorry, this is a duplicate of issue #11432. Failed to find that, and also failed to realize that python is now using hg and my svn checkout might be outdated. Sorry there. -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12695 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12696] pydoc error page due to lacking permissions on ./*
New submission from Martin von Gagern martin.vgag...@gmx.net: I'd like to be able to run pydoc -b in whatever directory I'm currently in. Most of the time that would be the root of my home directory, which is an ext4fs mount. So it has a subdirectory called lost+found for which I don't have any access permissions. As a result, the main pydoc info page will simply print an error message: OSError: [Errno 13] Permission denied: './lost+found' I'm not sure how best to address this. There are several possibilities that come to my mind: 1. Provide a command line switch to strip '.' from sys.path. 2. Skip any sys.path elements which cause exceptions, possibly printing a warning in addition to the remaining page content. 3. Skip any single subdirectry which causes an exception, as this more closely models what importing by name would do. 4. Explicitely skip lost+found, or perhaps any directory name which would be invalid as a module name. Obviously, the workaround is to change to a sufficiently empty directory before starting pydoc. So this is a minor issue, but annoying nevertheless. -- components: Library (Lib) messages: 141658 nosy: gagern priority: normal severity: normal status: open title: pydoc error page due to lacking permissions on ./* type: feature request versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12696] pydoc error page due to lacking permissions on ./*
Martin von Gagern martin.vgag...@gmx.net added the comment: The server continues all right. It's the browser window which displays the error message. Not much better in my opinion, though. To be completely accurate: currently the -b option doens't work as it should due to issue #11432. But using -p 0 and opening the link manually is a suitable workaround for now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4934] tp_del and tp_version_tag undocumented
Changes by Martin von Gagern martin.vgag...@gmx.net: -- nosy: +gagern ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4934 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11218] pattern=None when following documentation for load_tests and unittest.main()
New submission from Martin von Gagern martin.vgag...@gmx.net: If I follow the documentation at http://docs.python.org/library/unittest.html#unittest.main by putting the following two snippets of code in my module file: def load_tests(loader, standard_tests, pattern='test*.py'): # top level directory cached on loader instance this_dir = os.path.dirname(__file__) package_tests = loader.discover(start_dir=this_dir, pattern=pattern) standard_tests.addTests(package_tests) return standard_tests if __name__ == __main__: unittest.main() then the application will fail with an obscure error message: == ERROR: __main__ (unittest.loader.LoadTestsFailure) -- TypeError: object of type 'NoneType' has no len() -- Ran 1 test in 0.000s Monkeypatching unittest.loader._make_failed_load_tests to display a stack trace, I got this: Traceback (most recent call last): File /usr/lib64/python2.7/unittest/loader.py, line 71, in loadTestsFromModule return load_tests(self, tests, None) File tester.py, line 15, in load_tests package_tests = loader.discover(start_dir=this_dir, pattern=pattern) File /usr/lib64/python2.7/unittest/loader.py, line 204, in discover tests = list(self._find_tests(start_dir, pattern)) File /usr/lib64/python2.7/unittest/loader.py, line 247, in _find_tests if not self._match_path(path, full_path, pattern): File /usr/lib64/python2.7/unittest/loader.py, line 235, in _match_path return fnmatch(path, pattern) File /usr/lib64/python2.7/fnmatch.py, line 43, in fnmatch return fnmatchcase(name, pat) File /usr/lib64/python2.7/fnmatch.py, line 75, in fnmatchcase res = translate(pat) File /usr/lib64/python2.7/fnmatch.py, line 87, in translate i, n = 0, len(pat) TypeError: object of type 'NoneType' has no len() The error is due to the fact that pattern is passed as None to load_tests, but apparently loader.discover doesn't loke a None pattern. I would suggest that a) discover internally translates None to the default of 'test*.py' or b) the documentation is changed to cater for this common use case, i.e. by including a pattern is None case distinction in its load_tests snippet. In case b) is implemented but not a), it would be nice to have a more expressive error message by catching the error somewhat sooner. -- assignee: docs@python components: Documentation, Library (Lib) files: tester.py messages: 128579 nosy: docs@python, gagern priority: normal severity: normal status: open title: pattern=None when following documentation for load_tests and unittest.main() type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file20763/tester.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11218 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10680] argparse: titles and add_mutually_exclusive_group don't mix (even with workaround)
Martin von Gagern martin.vgag...@gmx.net added the comment: I've added a unit test for this nested mutex scenario. The attached patch includes the original fix as well, as for some reason the patch by loewis wouldn't apply to my tree automatically. -- nosy: +gagern Added file: http://bugs.python.org/file20548/issue10680_withTestcase.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10680 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue843590] 'macintosh' encoding alias for 'mac_roman'
Martin von Gagern martin.vgag...@gmx.net added the comment: Maybe I'm missing something here, but r84229 looks to me like aliasing 'macintosh' to itself, instead of to 'mac_roman'. 'csmacintosh' and 'mac' are not included at all, without any comment as to why they have been omitted. Makes me wonder why my issue843590_alias.patch wasn't applied as it is, but recreated instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue843590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern martin.vgag...@gmx.net added the comment: Wrong issue number again, or did you deliberately try to catch me in an infinite see-also loop? ;-) I've tried to work out what issue you meant, but failed so far. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1670765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern martin.vgag...@gmx.net added the comment: Here is the corresponding path for python3 (py3k branch). It's mostly the same, except for one additional test which ensures header preservation even if the maxheaderlen argument to Message.as_string is greater than 0. It's called test_long_headers_as_string_maxheaderlen. -- Added file: http://bugs.python.org/file15905/issue1670765_python3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1670765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern martin.vgag...@gmx.net added the comment: You missed a digit in the test comment: s/See issue 96843/See issue 968430/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1670765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern martin.vgag...@gmx.net added the comment: Let's get some traction here, please! Attached is a test case which will demonstrate the issue. It includes the content of test5.eml as a string so that it won't require additional files. It produces both human-readable output and a suitable exit status. Turning it into a unit test should be easy as well. It doesn't do signature verification, but uses simple string comparison instead. The rationale is that anything changing the string would break the signature as well. That should be enough for unit tests. Please change stage to patch review. -- Added file: http://bugs.python.org/file15893/issue1670765a.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1670765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern martin.vgag...@gmx.net added the comment: OK, here is a patch providing both two test cases and the fix for current trunk. Will probably hack something for python 3 as well, although there the Message.as_string approach works due to the new headerlength argument defaulting to 0. So there I'd adjust the patch I also included a second test e-mail together with two disabled test cases in order to address the whitespace issue I mentioned. Would be nice to have a fix for these as well, but I assume you don't want known to fail test cases without a fix in trunk unless it's really serious, right? In any case, the fact that there should be at least four tests, maybe more in the future, all dealing with signature preservation, led me to have a class dedicated to them, instead of only adding methods to one of the existing classes. I hope you agree with that decision. -- Added file: http://bugs.python.org/file15895/issue1670765_python2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1670765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue843590] 'macintosh' encoding alias for 'mac_roman'
Martin von Gagern martin.vgag...@gmx.net added the comment: Find attached (issue843590_rfc.patch) an implementation of the macintosh encoding as the RFC defines it. I don't suggest its inclusion; I would prefer the alias of this implementation, but either one is better than no 'macintosh' encoding at all. So if you really want that, here it is. -- keywords: +patch Added file: http://bugs.python.org/file15896/issue843590_rfc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue843590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue843590] 'macintosh' encoding alias for 'mac_roman'
Martin von Gagern martin.vgag...@gmx.net added the comment: And this patch (issue84359_alias.patch) is the alternative, 'macintosh' as an alias to 'mac_roman' as originally requested, along with a bunch of aliases registered with IANA. I'd prefer this approach over the preceding one, and hope someone will maybe review this for inclusion. -- Added file: http://bugs.python.org/file15897/issue843590_alias.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue843590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header
Changes by Martin von Gagern martin.vgag...@gmx.net: -- nosy: +gagern ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1974 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue843590] 'macintosh' encoding alias for 'mac_roman'
Martin von Gagern martin.vgag...@gmx.net added the comment: I did some further investigations here. Apple doesn't seem likely to offer any authoritative reference for the macintosh encoding, because all they ever seem to talk about is Roman. The only source for macintosh I could find is this RFC 1345, with the listed differences. The RFC states the Unicode 1.0 standard as its source. Yesterday I went to the library and thumbed through that volume. That, too, talks about the different macintosh encodings, one of which is called Roman and matches the one from current Unicode standards, except for 0xdb which used to be the currency sign back then but is euro now. On 2009-02-09 I also tried to ask Keld Simonsen, the author of the RFC, about this whole issue. I got no reply so far. On the whole, I get the impression that the macintosh encoding from RFC 1345 is pretty much without actual use. I see no real world application which actually uses it as it is defined, as most users intend it as the IANA-registered name for mac-roman. Python has two options, I believe. We could either do this by the book, and implement an encoding as it was defined, even though there is no known real world applicaton of that exact charset. Or we could be pragmatic, and postulate that the RFC is simply wrong, and every real world occurrence of macintosh intends to refer to mac-romand, in which case an alias would be appropriate. I would say, let's be pragmatic. When converting from unicode to macintosh, it might be possible to accomodate both mappings, and in this way avoid unmappable characters. As this doesn't deal well with the switched dashes, I guess I'd rather not do this, in order to avoid subtle issues from going undetected. It might be a good idea, however, to map both currecny sign and euro to the same byte, and choose one when mapping back to unicode. I don't think I can contribute much more information to this issue, and seeing as it has been open for years without much input, I take it neither will others. So I guess it is time to make a choice based on the information available. By the book, or pragmatic? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue843590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5128] compileall: consider ctime
Martin von Gagern martin.vgag...@gmx.net added the comment: Any progress with the review? By the way, what branch are we aiming for? I'm using 2.5 here, so I reported this issue against that version, and wrote the patch against that branch. I guess it should work for trunk as well, but the imports of with_statement from __future__ should probably be omitted there. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue843590] 'macintosh' encoding alias for 'mac_roman'
Martin von Gagern martin.vgag...@gmx.net added the comment: I had my first indication to rather use macintosh instead of mac_roman from Wikipedia http://en.wikipedia.org/wiki/Mac_OS_Roman which states that the charset part of a MIME content-type specification should be maciontosh. I'm not quoting this as any kind of authority, but rather to point out that it is likely for people to use this. I did a comparison of http://tools.ietf.org/rfc/rfc1345.txt (RFC) and ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT (UNI) using the attached perl script. The results: 3 codepoints unused in RFC but defined in UNI: f0, f6, f7 1 codepoint unused in UNI but defined in RFC: 7f 2 codepoints with slightly different character names, same meaning 9 codepoints with actually different definitions: a5: rfc 2219 BULLET OPERATOR uni 2022 BULLET c4: rfc e023 DUTCH GUILDER SIGN (IBM437 159) uni 0192 LATIN SMALL LETTER F WITH HOOK c6: rfc 0394 GREEK CAPITAL LETTER DELTA uni 2206 INCREMENT c9: rfc 22ef MIDLINE HORIZONTAL ELLIPSIS uni 2026 HORIZONTAL ELLIPSIS d0: rfc 2014 EM DASH uni 2013 EN DASH d1: rfc 2013 EN DASH uni 2014 EM DASH d7: rfc 25c6 BLACK DIAMOND uni 25ca LOZENGE db: rfc 00a4 CURRENCY SIGN uni 20ac EURO SIGN f8: rfc 203e OVERLINE uni 00af MACRON a5 and c6 could be different interpretations of symbols that look pretty much the same. The introduction of the euro sign instead of the generic currency sign seems to be a recent modification documented in UNI. The change of the order of the dashes seems really confusing. Notice also this line in the RFC: rem source: The Unicode Standard ver1.0, ISBN 0-201-56788-1, Oct 1991 So it looks like the RFC used the unicode definition as its source. What part of it I'm not sure, and where the differences come I'm even less sure. My next steps: * Look for further references, e.g. from apple, and compare them as well * Try some things out on a mac, see how it behaves in real life * Compare all this to the current python implementation * Write a patch to either provide an alias or a new charset macintosh Help welcome. -- nosy: +gagern Added file: http://bugs.python.org/file12982/compare.pl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue843590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5128] compileall: consider ctime
Martin von Gagern martin.vgag...@gmx.net added the comment: Not being a regular Python programmer myself, I've never even heard of a context manager before, but this latest patch should fit the bill. As for tests, I believe that a few two-second sleeps (as FAT has only two second resolution iirc) should avoid the kind of problem you describe. This latest patch includes unit tests, where the test_backdate fails for current implementation. The others are there to express even more basic assumptions, and can be dropped if you worry about those seconds spent running obvious tests. The tests are based on test_dircache, from which I copied and adapted the infrastructure for dealing with a temporary directory. Added file: http://bugs.python.org/file12937/compileall-timestamp3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5128] compileall: consider ctime
Martin von Gagern martin.vgag...@gmx.net added the comment: Like this? Should the magic number be checked as well, and if so, against what value? I couldn't find that constant in any structure accessible from python, and jumping through hoops seems too much, as updating the python version should probably result in all system-wide modules being updated as well, at least on a well-maintained system. Added file: http://bugs.python.org/file12922/compileall-timestamp1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5128] compileall: consider ctime
Martin von Gagern martin.vgag...@gmx.net added the comment: Next iteration. With magic number, and now also closing the file again. I changed from unpack and number comparison to pack and string comparison, makes things a bit easier, as there is only one comparison, and as underflow of the packed data isn't an issue any more. Would you prefer the use of private marshal functions, as bootstrap does, over the struct packing as I do here? Looking forward to your review. Added file: http://bugs.python.org/file12924/compileall-timestamp2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5128] compileall: consider ctime
New submission from Martin von Gagern martin.vgag...@gmx.net: When trying to decide whether or not a given file needs to be recompiled, the inode creation time should be taken into account along with the file modification time. Scenario: Suppose you have three times, A B C D. At time A, you package version 1 of foo.py. At time B, you package version 2. At time C you install version 1 onto some system, and byte-compile it for all users. Therefore foo.py has mtime A and ctime C, and foo.pyc has both mtime C. At time D you delete foo.py from version 1 and install version 2. Then you byte-compile it without force. At that time, foo.py has mtime B (because that was when it was packaged) but ctime D (because that was when the file was created). foo.pyc has mtime C (because that was when it was last modified). The current comparison compares only mtimes, sees C B, and skips foo.py. With this patch in place, it will check for C max(B, D), which is not the case, and thus recompile foo.c. In other words, max(st_mtime, st_ctime) can be interpreted as the last time a file at a given path was changed, either through modification of its contents (mtime) or deletion followed by recreation (ctime). Installation systems that overwrite files without deleting them before still are in the same trouble as before, but all others will benefit from this. See also: http://bugs.gentoo.org/256953 -- components: Library (Lib) messages: 80939 nosy: gagern severity: normal status: open title: compileall: consider ctime type: feature request versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5128] compileall: consider ctime
Changes by Martin von Gagern martin.vgag...@gmx.net: -- keywords: +patch Added file: http://bugs.python.org/file12917/compileall-ctime.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5128 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern added the comment: Looks like I missed your comments on this patch. What kind of tests do you have in mind? Tests demonstrating where current implementation fails and my patch will help? Or rather tests checking that this patch won't break anything else? The former would be easy enough, but for the latter I'm not sure how far this would go, as people tend to make strange assumptions I would never have thought of. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1670765 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1670765] email.Generator: no header wrapping for multipart/signed
Martin von Gagern added the comment: Take the attached test5.eml. Run it through the following python script: import email print (email.message_from_file(open(test5.eml)).as_string(False)) The result will have both instances of the X-Long-Line header rewrapped. As the second instance is included in the digest calculation, the signature verification will now fail. This is a real world signature algorithm, following RFC 3156 (if I didn't make a mistake). If you have an OpenPGP-enabled mailreader (e.g. enigmail for Thunderbird) and have some way of injecting a mail as is into your mail folders (e.g. a maildir-based server), then you can use this setup to verify that the signature was correct in the first place and is broken after parsing and reconstruction by python. If you don't have such a setup available, and you don't believe me that rewrapping the header breaks the signature, then I could either devise some unrealistic but easy-to-check signing process, or could try to get this working with an S/MIME signature using an X.509 certificate. I would rather avoid this, though. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1670765 _---BeginMessage--- This is the signed contents. signature.asc Description: OpenPGP digital signature ---End Message--- ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
