[ python-Bugs-1672853 ] Error reading files larger than 4GB
Bugs item #1672853, was opened at 2007-03-03 00:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: Error reading files larger than 4GB Initial Comment: When reading test files larger than 4GB, sometimes two lines are merged into a single line. The problem is reproducible on Windows 2K SP4 with both Python 2.4 and 2.5. It does not appear to occur on Linux. I have attached a test case that creates the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 11:16 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 10:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 01:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 11:16 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 10:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 10:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 10:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 01:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by fred2k You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: fred2k (fred2k) Date: 2007-03-03 12:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 13:05 Message: Logged In: YES user_id=21627 Originator: NO In what directory? PCbuild or PCbuild8? -- Comment By: fred2k (fred2k) Date: 2007-03-03 12:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 12:16 Message generated for change (Comment added) made by fred2k You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: fred2k (fred2k) Date: 2007-03-03 13:08 Message: Logged In: YES user_id=1733250 Originator: YES As I tried to build with MVS2005, I used the sln file in the PCBuild8 directory -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 13:05 Message: Logged In: YES user_id=21627 Originator: NO In what directory? PCbuild or PCbuild8? -- Comment By: fred2k (fred2k) Date: 2007-03-03 12:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 11:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 11:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 02:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672336 ] Building python 2.5 for AMD64 (windows) and VS2005
Bugs item #1672336, was opened at 2007-03-02 11:16 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: fred2k (fred2k) Assigned to: Kristj�n Valur (krisvale) Summary: Building python 2.5 for AMD64 (windows) and VS2005 Initial Comment: When building pythoncore for AMD64 (WIndows) on VS2005, I get the following error : 3>generate buildinfo 3>cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON ..\Modules\getbuildinfo.c -Fogetbuildinfo.o -I..\Include -I..\PC 3>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 3>Copyright (C) Microsoft Corporation. All rights reserved. 3>getbuildinfo.c 3>Linking... 3>LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored 3>getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' 3>Build log was saved at "file://d:\users\fbr\python build\Python-2.5\PCbuild8\amd64-temp-release\pythoncore\BuildLog.htm" 3>pythoncore - 1 error(s), 225 warning(s) I already looked for the issue on google and on the ML archive (http://mail.python.org/pipermail/python-dev/2006-March/062753.html) but the workaround explained there (checking vsextcompiler) is specific for VC2003. Has anyone solved this problem ? -- >Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 13:13 Message: Logged In: YES user_id=1262199 Originator: NO Ok, I will look into this when I get the oppertunity. Possibly these .sln file or .vcproj have gotten contaminated with some strange options... -- Comment By: fred2k (fred2k) Date: 2007-03-03 12:08 Message: Logged In: YES user_id=1733250 Originator: YES As I tried to build with MVS2005, I used the sln file in the PCBuild8 directory -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 12:05 Message: Logged In: YES user_id=21627 Originator: NO In what directory? PCbuild or PCbuild8? -- Comment By: fred2k (fred2k) Date: 2007-03-03 11:53 Message: Logged In: YES user_id=1733250 Originator: YES What do you mean by PCBuild8 build setup ?? I only see the files that are necessary to the build in the directory. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 10:57 Message: Logged In: YES user_id=1262199 Originator: NO This suggest to me that the reporter is not using the PCBuild8 build setup to do this, since that should have all-new flags. I will still try to repro, though. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 10:40 Message: Logged In: YES user_id=21627 Originator: NO USECL and USELINK is easily resolved: that's an option of vsextcomp, used to build the "official" AMD64 and Itanium binaries with the 2003 build environment, vsextcomp, and the platform compilers. Apparently, when the VS 2005 projects were created, the AMD64 and Itanium targets weren't updated. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-03-03 10:23 Message: Logged In: YES user_id=1262199 Originator: NO Well, it sounds like he is trying to link modules compiled for different machines. /USECL or /USELINK aren't options for MSVC, so something fishy is going on there. I will try to reproduce when I get the chance -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-03 01:49 Message: Logged In: YES user_id=21627 Originator: NO Kristjan, can you take a look? If not, please unassign. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672336&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668295 ] Strange unicode behaviour
Bugs item #1668295, was opened at 2007-02-25 12:10
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668295&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Santiago Gala (sgala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange unicode behaviour
Initial Comment:
I know that python is very funny WRT unicode processing, but this defies all my
knowledge.
I use the es_ES.UTF-8 encoding on linux. The script:
python -c "print unicode('á %s' % 'éí','utf8') " works, i.e., prints á éí in
the next line.
However, if I redirect it to less or to a file, like
python -c "print unicode('á %s' % 'éí','utf8') " >test
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0:
ordinal not in range(128)
Why is the behaviour different when stdout is redirected? How can I get it to
do "the right thing" in both cases?
--
>Comment By: Santiago Gala (sgala)
Date: 2007-03-03 14:22
Message:
Logged In: YES
user_id=178886
Originator: YES
>This is not magic. "print" looks for an "encoding" attribute on the file
>it is printing to. This is the terminal encoding for sys.stdout and None
>for other files.
I'll correct you:
"print" looks for an "encoding" attribute on the file it is printing to.
This is the terminal encoding for sys.stdout *if sys.stdout is a terminal*
and None when sys.stdout is not a terminal.
After all, the bug reported is that *the same program* behaved different
when used standalone than when piped to less:
$ python -c "import sys; print sys.stdout.encoding"
UTF-8
$ python -c "import sys; print sys.stdout.encoding" | cat
None
If you say that this is intended, not a bug, that an external process is
altering the behavior of a python program, I'd just leave it written to
warn other naive people like myself, that thinks that an external program
should not influence python behavior (with *the same environment*):
$ locale
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=es_ES.UTF-8
But I take it as a design flaw, and against all pythonic principles,
probably coming from the fact that a lot of python developers/users are
windows people that don't care about stdout at all.
IMO, the behavior should be either:
- use always None for sys.stdout
- use always LC_CTYPE or LANG for sys.stdout
I prefer the second one, as when I pipe stdout, after all, I expect it to
be honoring my locale settings. Don't forget that the same person that
types "|" after a call to python can type LC_ALL=blah before, while s/he
can't sometimes modify the script because it is out of their permission
set.
The implementation logic would be simpler too, I guess.
And more consistent with jython (it uses the second "always LC_CTYPE"
solution). Not sure about iron-python or pypy.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-02-26 00:27
Message:
Logged In: YES
user_id=849994
Originator: NO
> >>> sys.getfilesystemencoding()
> 'UTF-8'
>
> so python is really dumb if print does not know my filesystemencoding,
but
> knows my terminal encoding.
the file system encoding is the encoding of file names, not of file
content.
> I though breaking the least surprising behaviour was not considered
> pythonic, and now you tell me that having a program running on console
but
> issuing an exception when redirected is intended. I would prefer an
> exception in both cases. Or, even better, using
> sys.getfilesystemencoding(), or allowing me to set defaultencoding()
I agree that using the terminal encoding is perhaps a bit too DWIMish, but
you
can always get consistent results if you *do not write Unicode strings
anywhere*.
> Do you mean that I need to say print unicode(whatever).encode('utf8'),
> like:
>
> >>> a = unicode('\xc3\xa1','utf8') # instead of 'á', easy to read and
> understand, even in files encoded as utf8. Assume this is a literal or
> input
No. You can directly put Unicode literals in your files, with u'...'.
For that to work, you need to tell Python the encoding your file has,
using the coding cookie (see the docs).
> ...
> >>> print unicode(a).encode('utf8') # because a could be a number, or a
> different object
>
> every time, instead of "a='á'; print a"
> Cool, I'm starting to really love it. Concise
[ python-Feature Requests-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-04 00:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-04 00:21 Message generated for change (Settings changed) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) >Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
