[issue2142] difflib.unified_diff(...) produces invalid patches
Changes by Trent Mick tre...@gmail.com: -- assignee: - trentm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] difflib.unified_diff(...) produces invalid patches
Trent Mick tre...@gmail.com added the comment: c.f. some discussion on python-dev here: http://mail.python.org/pipermail/python-dev/2010-October/104501.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8029] bug in 2to3 dealing with print FOO, followed by sys.stdout.write('')
New submission from Trent Mick tre...@gmail.com:
According to
http://docs.python.org/reference/simple_stmts.html#the-print-statement the
following with result in the print statement NOT printing a trailing space:
import sys
print uASD,; sys.stdout.write(u)
However, 2to3 currently translates this to:
import sys
print(ASD, end=' '); sys.stdout.write()
It *should* translate to:
import sys
print(ASD, end='')
You can also see the discussion of this on this lib3to2 bug report:
http://bitbucket.org/amentajo/lib3to2/issue/13/print-3-end-isnt-translated-properly
and translation of this between 2to3 and 3to2 here:
http://pythontranslationparty.appspot.com/6004/
--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 100194
nosy: trentm
severity: normal
status: open
title: bug in 2to3 dealing with print FOO, followed by sys.stdout.write('')
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8029
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate Python interpreter (so 3.1's idle.bat does not accidently use python26.exe)
Changes by Trent Mick tre...@gmail.com: -- nosy: +trentm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'
Trent Mick tre...@gmail.com added the comment: Tarek, This should not affect anyone using gcc or g++ on AIX because of this check just before the lines added by this patch: elif compiler[:3] == gcc or compiler[:3] == g++: return -Wl,-R + dir The intention of the patch is to fix linker argument handling with NOT using gcc, i.e. when using IBM's native AIX compiler. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff)
Trent Mick tre...@gmail.com added the comment: Here is a new patch that also fixes the same issue in difflib.context_diff() and adds a couple test cases. -- stage: test needed - patch review title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char - naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff) Added file: http://bugs.python.org/file14082/python_difflib_no_eol.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace
Changes by Trent Mick [EMAIL PROTECTED]: -- nosy: +trentm ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick [EMAIL PROTECTED] added the comment: Added file: http://bugs.python.org/file11723/pymacconfig.h.patch I'll test that on my end tomorrow -- though it looks like it will work fine. Thanks. -- title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC - PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick [EMAIL PROTECTED] added the comment:
I get:
sizeof(_Bool)=4 bytes
on a G4 PPC.
Same thing on a G5 PPC:
$ cat main.c
#include stdio.h
int main(void) {
printf(sizeof(_Bool) is %d\n, sizeof(_Bool));
}
$ gcc main.c
$ ./a.out
sizeof(_Bool) is 4
--
title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS
X/PowerPC - PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS
X/PowerPC
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4060
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick [EMAIL PROTECTED] added the comment: What if you compile using 'gcc -arch ppc64 main.c'? $ gcc -arch ppc64 main.c $ ./a.out sizeof(_Bool) is 1 As you figured out. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=
Trent Mick [EMAIL PROTECTED] added the comment: Does this also affect sys.byteorder and the struct module ? Doesn't seem to affect sys.byteorder: $ /usr/bin/python -c import sys; print sys.byteorder big $ python2.6 -c import sys; print sys.byteorder big I think those would be more important to get right than the UTF-16 codec, since this only uses the native byte ordering for increased performance and compatibility with other OS tools. Since UTF-16 is not wide-spread on Mac OS X, it's not so much an issue... It is an issue for Python extensions that use that API. For example, it is the cause of recent Komodo builds not starting Mac OS X/PowerPC (http://bugs.activestate.com/show_bug.cgi?id=79366) because the PyXPCOM extension and embedded Python 2.6 build was getting UTF-16 data mixed up when talking with Mozilla APIs. it would be on Windows. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=
Trent Mick [EMAIL PROTECTED] added the comment: BTW: Does this simplified approach really work for Python on Mac OS X It works for Python 2.5: http://svn.python.org/view/*checkout*/python/branches/release25-maint/configure.in?rev=66299 search for BIGENDIAN. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=
Changes by Trent Mick [EMAIL PROTECTED]: -- keywords: +patch Added file: http://bugs.python.org/file11720/issue4060_macosx_endian.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Trent Mick [EMAIL PROTECTED] added the comment: The failure is in the DuplicateHandle call that subprocess makes on, in this case, the stdin handle (as returned by `GetStdHandle(STD_INPUT_HANDLE)`) call earlier. Two cases here: 1. When this is run in a subsystem:windows process (like PythonWin or IDLE) that is launched from Windows Explorer (e.g. from a Start Menu shortcut or Desktop shortcut) then `GetStdHandle(STD_INPUT_HANDLE)` returns None. [http://msdn.microsoft.com/en-us/library/ms683231(VS.85).aspx] If an application does not have associated standard handles, such as a service running on an interactive desktop, and has not redirected them, the return value is NULL. In this case you *don't* get the error that Todd described, because the code path taken in subprocess.py then use CreatePipe for the `p2cread` variable on which `DuplicateHandle` is called. 2. However, when the subsystem:windows process is launched from the cmd.exe shell the `GetStdHandle` call returns a value -- in Todd's and my testing, the value 3. The code path in subprocess.py then calls `DuplicateHandle` on this in `Popen._make_inheritable`. This fails with traceback Todd posted. My *guess* at what the problem is stems from this comment in the MSDN docs on console handles: [http://msdn.microsoft.com/en-us/library/ms682075(VS.85).aspx] A process can use the DuplicateHandle function to create a duplicate console handle that has different access or inheritability from the original handle. Note, however, that a process can create a duplicate console handle only for its own use. This differs from other handle types (such as file, pipe, or mutex objects), for which DuplicateHandle can create a duplicate that is valid for a different process. My guess is that the stdin handle (3) is inherited from the shell (cmd.exe) and attempting to `DuplicateHandle` on it violates the clause that you can on dupe a console handle of your own. I'm not sure of that though. Anyone else have more light to shed on this? If this is the case I'm not sure what a possible or good solution could be for subprocess. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick [EMAIL PROTECTED] added the comment: Thanks Ronald. Any comment on http://bugs.python.org/msg69936 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick [EMAIL PROTECTED] added the comment: This bug should be re-opened. The patch to configure.in wasn't quite right. I'm attaching a slight fix. `autoconf`ing removes one level of square brackets in the 'sed' command to create $tgt. (Q about the issue tracker: I'm unable to change the Status field on this bug. I'm guessing that is by design, right? I.e., only certain people have the privs to change bug status?) -- keywords: +patch type: - compile error Added file: http://bugs.python.org/file10956/issue3381_configure_fix.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick [EMAIL PROTECTED] added the comment: Ronald, The @ARCH_RUN_32BIT@ also needs to be added to two places in Mac/Makefile.in (as indicated in issue 3393), no? Would you like me to make that change? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac make installmacsubtree` fails on Mac OS X 10.5 because of r63955
Trent Mick [EMAIL PROTECTED] added the comment: The current trunk should be correct, there are no explicit calls to the arch command left, all go through the configure replacement magic. $ svn info Path: . URL: svn+ssh://[EMAIL PROTECTED]/python/trunk/Mac Repository Root: svn+ssh://[EMAIL PROTECTED] Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 65091 Node Kind: directory Schedule: normal Last Changed Author: ronald.oussoren Last Changed Rev: 65091 Last Changed Date: 2008-07-17 22:48:03 -0700 (Thu, 17 Jul 2008) Properties Last Updated: 2008-07-17 22:55:32 -0700 (Thu, 17 Jul 2008) [EMAIL PROTECTED]:~/src/python/Mac] $ svn up Makefile.in At revision 65091. [EMAIL PROTECTED]:~/src/python/Mac] $ grep arch - Makefile.in $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \ $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST) Apologies if I am missing something. Your patches for issue 3381 did not include a change to Mac/Makefile.in. Trent ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac make installmacsubtree` fails on Mac OS X 10.5 because of r63955
Trent Mick [EMAIL PROTECTED] added the comment: Similar change in Mac/IDLE/Makefile.in: - --- python/trunk/Mac/IDLE/Makefile.in (original) +++ python/trunk/Mac/IDLE/Makefile.in Thu Jun 5 14:58:24 2008 @@ -42,7 +42,7 @@ $(srcdir)/../Icons/PythonSource.icns \ $(srcdir)/../Icons/PythonCompiled.icns Info.plist rm -fr IDLE.app - $(RUNSHARED) $(BUILDPYTHON) $(BUNDLEBULDER) \ + $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(BUNDLEBULDER) \ --builddir=. \ --name=IDLE \ --link-exec \ - ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac make installmacsubtree` fails on Mac OS X 10.5 because of r63955
Trent Mick [EMAIL PROTECTED] added the comment: Alternative potential solution: use the ARCHPREFERENCE environment variable as described in the Mac OS X 10.5 arch man page. Ronald, if you could test if that works for you on 10.5, then presumably setting that environment var would be safely ignored on Mac OS X 10.5. Thoughts? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
New submission from Trent Mick [EMAIL PROTECTED]:
Configuring with --enable-universalsdk fails on Mac OS X 10.4/x86
because of a change in r63997. This in the python trunk (i.e. the 2.6 tree).
The failure looks like this:
$ ./configure --enable-framework --enable-universalsdk
...
checking for log1p... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
See `config.log' for more details.
And the appropriate details in config.log are:
...
configure:21540: checking size of wchar_t
configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c 5
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or
directory)
configure:21878: $? = 1
configure: program exited with status 1
configure: failed program was:
...
The command being run:
gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c
is $ac_link. Here is a dump of relevant variables at that point in
configure:
--
LDFLAGS is -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
CFLAGS is -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2
CPPFLAGS is
CC is gcc
ac_link is $CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS 5
--
The problem is that r63997
(http://mail.python.org/pipermail/python-checkins/2008-June/070612.html)
added this line to configure.in for Mac OS X:
CFLAGS=${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}
That results in the failure above: ld complaining about
-isysroot/-syslibroot being specified twice on the command line.
Ronald,
What was the build issue on OSX 10.4 that the was meant to be fixed.
Can it be fixed without that configure change to CFLAGS?
--
components: Build
messages: 69805
nosy: ronaldoussoren, trentm
severity: normal
status: open
title: `./configure --enable-framework --enable-universalsdk` fails because of
change in r63997
versions: Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3381
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick [EMAIL PROTECTED] added the comment: Yet another version: configure-patch-3381-2.txt is a slight enhancement of the first version. Ronald, Did that accidentally not get attached? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
New submission from Trent Mick: When comparing content with difflib, if the resulting diff covers the last line of one or both of the inputs that that line doesn't end with an end-of-line character(s), then the generated diff lines don't include an EOL. Fair enough. Naive (and I suspect typical) usage of difflib.unified_diff(...) is: diff = ''.join(difflib.unified_diff(...)) This results in an *incorrect* unified diff for the conditions described above. from difflib import * gen = unified_diff(one\ntwo\nthree.splitlines(1), ...one\ntwo\ntrois.splitlines(1)) print ''.join(gen) --- +++ @@ -1,3 +1,3 @@ one two -three+trois The proper behaviour would be: gen = unified_diff(one\ntwo\nthree.splitlines(1), ...one\ntwo\ntrois.splitlines(1)) print ''.join(gen) --- +++ @@ -1,3 +1,3 @@ one two -three \ No newline at end of file +trois \ No newline at end of file I *believe* that \ No newline at end of file are the appropriate markers -- that tools like patch will know how to use. At least this is what svn diff generates. I'll try to whip up a patch. Do others concur that this should be fixed? -- components: Library (Lib) messages: 62543 nosy: trentm severity: normal status: open title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2142 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
Trent Mick added the comment: At a glance I suspect this patch will work back to Python 2.3 (when difflib.unified_diff() was added). I haven't looked at the Py3k tree yet. Note: This *may* also applied to difflib.context_diff(), but I am not sure. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2142 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
Trent Mick added the comment: Attached is a patch against the Python 2.6 svn trunk for this. -- versions: +Python 2.3, Python 2.4, Python 2.6 Added file: http://bugs.python.org/file9460/python_difflib_unified_diff.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2142 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
