[issue4898] {context, unified}_diff add spurious trailing whitespace if fromfiledate/tofiledate are emptyk
New submission from Adeodato Simó d...@net.com.org.es:
Hello.
I recently noticed that Bazaar's unified_diff() was emiting ---/+++
lines with a trailing whitespace if fromfiledate/tofiledate were the
empty string. (Which was bad because a program to detect spurious
trailing whitespace in diffs would flag them as errors.)
A patch [1] was committed recently in their tree. During the
discussion, it was pointed out that the affected function was a copy
of Python's own unified_diff() in difflib, which suffered the same
problem.
[1]: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3923
I'm now attaching a patch to fix this issue in Python. It'd be great
if you'd consider applying it. (It seems that the correct character to
separate dates is a tab and not a space; if you feel changing this is
breaking backwards compatibility, feel free to s/\t/ / in my patch.)
Thanks.
--
components: Library (Lib)
files: python_difflib_fix.diff
keywords: patch
messages: 79473
nosy: dato, jameinel
severity: normal
status: open
title: {context,unified}_diff add spurious trailing whitespace if
fromfiledate/tofiledate are emptyk
type: behavior
Added file: http://bugs.python.org/file12668/python_difflib_fix.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4898
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4898] {context, unified}_diff add spurious trailing whitespace if fromfiledate/tofiledate are emptyk
Adeodato Simó d...@net.com.org.es added the comment: Who is the author of this patch? I am the author of the patch attached to this bug report. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4898 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
Adeodato Simó d...@net.com.org.es added the comment: Hello, I see that something akin to my proposed patch was applied, but I think the order of the arguments to shutil.copymode was reversed in the process. This function takes (src, dst) as arguments, and we want permissions to flow backup - newfile, and not the the other way around. Thanks already. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4631] urlopen returns extra, spurious bytes
Adeodato Simó d...@net.com.org.es added the comment: Does the same thing happen with 2.6? No, I can't reproduce with 2.6.1. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4631] urlopen returns extra, spurious bytes
Adeodato Simó d...@net.com.org.es added the comment: FWIW, there are trailing spurious bytes too And in the middle of the document as well. Each time there's a chunk, I guess? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4661] email.parser: impossible to read messages encoded in a different encoding
New submission from Adeodato Simó d...@net.com.org.es: Currently, email.parser/feedparser can only parse messages that come as a string, or from a file opened in text mode. Email messages, however, can contain 8bit characters in any encoding other than the local one (yet still be valid e-mails, of course), so I think a method is needed to have the parser be able to receive bytes. At the moment, and as far as I can see, it's not possible to parse some perfectly valid messages with python 3.0. I don't think it's appropriate to ask that files be opened with the proper encoding, and then for the parser to read them. First, it is not possible to know what encoding that would be without parsing the message. And second, a message could contain parts in different encoding, and many mailboxes with random messages most certainly do. Also, message objects will need a way to return a bytes repreentation, for the reasons explained above, and particularly if one wants to write back the message without modifying it. -- components: Library (Lib) messages: 77807 nosy: dato severity: normal status: open title: email.parser: impossible to read messages encoded in a different encoding versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4661 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
Adeodato Simó [EMAIL PROTECTED] added the comment: Thanks for the report! Fixed in r67674. I'm afraid I'm unfamiliar with Python development procedures: that commit was committed to /sandox, is that expected? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4631] urlopen returns extra, spurious bytes
New submission from Adeodato Simó [EMAIL PROTECTED]:
This is very odd, but it was reproduced by people in #python as well.
Compare, in python 2.5:
urllib.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline()
'From [EMAIL PROTECTED] Tue Dec 11 11:32:47 2001\n'
To the equivalent in python 3.0:
urllib.request.urlopen('http://bugs.debian.org/cgi-bin/bugreport.cgi?mbox=yes;bug=123456').readline()
b'f65\r\n'
--
components: Library (Lib)
messages: 77603
nosy: dato
severity: normal
status: open
title: urlopen returns extra, spurious bytes
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4631
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
Adeodato Simó [EMAIL PROTECTED] added the comment: Yes, it will be merged into the trunk eventually. Great, thank you and sorry for the noise. Also, is this fix elegible for the 3.0 branch? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
New submission from Adeodato Simó [EMAIL PROTECTED]: Hello, after using 2to3 --write over some scripts, I found it very cumbersome having to run `chmod +x` on each of them afterwards. The attached patch is a possible way to fix this issue. It'd be great if somebody could apply it, or write a more appropriate fix. -- components: 2to3 (2.x to 3.0 conversion tool) files: 2to3_preserve_mode.diff keywords: patch messages: 77349 nosy: dato severity: normal status: open title: 2to3 drops executable bit with --write versions: Python 3.0 Added file: http://bugs.python.org/file12291/2to3_preserve_mode.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4602] 2to3 drops executable bit with --write
Changes by Adeodato Simó [EMAIL PROTECTED]: -- type: - behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
