STINNER Victor added the comment:
is it correct that this bug no longer appears in Python 2.7.3?
Martin wrote that it cannot be fixed in Python 2: For 2.6, I don't think
fixing it is feasible.
The fix is to upgrade your application to Python 3.
--
Michael Herrmann added the comment:
Hi,
is it correct that this bug no longer appears in Python 2.7.3? I checked the
changelogs of 2.7, but couldn't find anything.
Thanks!
Michael
--
nosy: +mherrmann.at
___
Python tracker rep...@bugs.python.org
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2128
___
___
David-Sarah Hopwood david-sa...@jacaranda.org added the comment:
The following code is being used to work around this issue for Python 2.x in
Tahoe-LAFS:
# This works around http://bugs.python.org/issue2128.
GetCommandLineW = WINFUNCTYPE(LPWSTR)((GetCommandLineW, windll.kernel32))
David-Sarah Hopwood david-sa...@jacaranda.org added the comment:
Sorry, missed out the imports:
from ctypes import WINFUNCTYPE, windll, POINTER, byref, c_int
from ctypes.wintypes import LPWSTR, LPCWSTR
--
___
Python tracker
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Martin, you are right that they are not from the same reason as that issue.
gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/
-fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-I. -IInclude
Martin v. Löwis [EMAIL PROTECTED] added the comment:
What warnings precisely are you seeing? I didn't see anything in the 3k
branch (not even for #2388, as PyErr_Format doesn't have the GCC format
attribute in 3k, unlike 2.x).
__
Tracker [EMAIL PROTECTED]
Martin v. Löwis [EMAIL PROTECTED] added the comment:
This is now fixed in r62178 for Py3k. For 2.6, I don't think fixing it
is feasible.
--
resolution: - fixed
status: open - closed
versions: -Python 2.6
__
Tracker [EMAIL PROTECTED]
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Here is a patch that redoes the entire argv handling, in terms of
wchar_t. As a side effect, it also changes the sys.path handling to use
wchar_t.
--
keywords: +patch
Added file: http://bugs.python.org/file9647/wchar.diff
Martin v. Löwis added the comment:
I dislike the double decoding, and would prefer if sys.argv would be
created directly from the wide command line.
In addition, I think the patch is incorrect: it ignores the arguments to
Py_Main, which is a documented API function.
One solution might be to
Giovanni Bajo added the comment:
mbstowcs uses LC_CTYPE. Is that correct and consistent with the way
default encoding under UNIX is handled by Py3k?
Would a Py_MainW or similar wrapper be easier on the UNIX guys? I'm just
asking, I don't have a definite idea.
__
Martin v. Löwis added the comment:
mbstowcs uses LC_CTYPE. Is that correct and consistent with the way
default encoding under UNIX is handled by Py3k?
It's correct, but it's not consistent with the default encoding - there
isn't really any default encoding in Py3k. More specifically,
Giovanni Bajo added the comment:
I'm attaching a simple patch that seems to work under Py3k. The trick is
that Py3k already attempts (not sure how or why) to decode argv using
utf-8. So it's sufficient to setup argv as UTF8-encoded strings.
Notice that brings the output of python à from
New submission from Giovanni Bajo:
Under Windows, sys.argv is created through the Windows ANSI API.
When you have a file/directory which can't be represented in the
system encoding (eg: a japanese-named file or directory on a Western
Windows), Windows will encode the filename to the system
14 matches
Mail list logo
