STINNER Victor victor.stin...@haypocalc.com added the comment:
Another remark. In the poplib section, there is a paragraph about asyncore: I
don't see how both are related.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
In the What's new in 3.2: there is no mention of the PEP 3003 (Python Language
Moratorium). May we add a section What is not new in 3.2? :-) This PEP is
something specific to Python 3.2
STINNER Victor victor.stin...@haypocalc.com added the comment:
It looks like your patch fixes #10829: you should add tests for that, you can
just reuse the tests of my patch (attached to #10829).
---
unicode_format() looks suboptimal.
+memset(buffer, ' ', width);
+width_unicode
New submission from STINNER Victor victor.stin...@haypocalc.com:
If you have an undecodable filenames on UNIX, Python 3 escapes undecodable
bytes using surrogates. pydoc: HTMLDoc.index() uses indirectly os.listdir()
which does such operation, and later filenames are encoded to UTF-8 (the whole
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oops, my isUndecodableFilename() example is wrong. PEP 383 only uses
U+DC80..U+DCFF range:
def isUndecodableFilename(filename):
return any((0xDC80 = ord(ch) = 0xDCFF) for ch in filename)
Example of undecodable filename: b'bla
New submission from STINNER Victor victor.stin...@haypocalc.com:
Since version 3.2, Python uses the locale encoding in
PyUnicode_EncodeFSDefault() using _Py_wchar2char() and _Py_char2wchar() until
the codec registry is initialized and the locale codec is loaded (until
initfsencoding() is done
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
components: +Unicode
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11187
___
___
Python
STINNER Victor victor.stin...@haypocalc.com added the comment:
test_undecodable_code() in test_cmd_line had a similar issue: on FreeBSD,
Solaris and Mac OS X, even if the locale is C (and nl_langinfo(CODESET)
announces ASCII), _Py_char2wchar() (mbstowcs) decoded b'\xff' as '\xff' (use
ISO
STINNER Victor victor.stin...@haypocalc.com added the comment:
See also issue #11193 (another locale issue on AIX).
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11190
STINNER Victor victor.stin...@haypocalc.com added the comment:
can we use str.encode() function to convert string into bytes ?
Can you try different ZIP archivers to check which encoding is expected?
WinZip, WinRAR, 7-zip, zip command line program on Linux, etc.
And do you have any reference
New submission from STINNER Victor victor.stin...@haypocalc.com:
PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithFilenameObject(int, const
char *); has a strange prototype: FilenameObject usually indicates a
PyObject* argument, not a char* argument. The function doesn't exist in
Python
STINNER Victor victor.stin...@haypocalc.com added the comment:
File .../Lib/test/test_time.py, line 351, in test_mktime
self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range
I don't know which values are out of range. But I guess that the test fails
because
STINNER Victor victor.stin...@haypocalc.com added the comment:
I don't understand why the test pass on FreeBSD, Solaris and
Mac OS X, but not on AIX.
Oh, the command line and the filesystem encodings may be different.
test_undecodable_env() of test_subprocess.py uses os.environ which uses
STINNER Victor victor.stin...@haypocalc.com added the comment:
sys.getfilesystemencoding()
'iso8859-1'
Ok, I expected this result.
Can you also try:
$ LC_ALL=C ./python -c import sys; print(ascii(sys.argv)) $(echo -ne
abc\xff)
['-c', 'abc\udcff']
$ LC_ALL=C python3.1 -c import locale
STINNER Victor victor.stin...@haypocalc.com added the comment:
test.jml is a ZIP archive, not a gzip archive.
gzip -d is kind enough to unpack it even if it is ZIP file and not a gzip
file.
So it's not a Python bug at all.
--
nosy: +haypo
resolution: - invalid
status: open - closed
STINNER Victor victor.stin...@haypocalc.com added the comment:
So test_negative is now OK
Ok, I converted your comment to a patch: strftime_aix.patch.
--
keywords: +patch
Added file: http://bugs.python.org/file20762/strftime_aix.patch
___
Python
STINNER Victor victor.stin...@haypocalc.com added the comment:
but tm_wday = 42 did not solve the problem it seems.
Can you try with tm_yday=-1 or tm_isdst=-2?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11188
STINNER Victor victor.stin...@haypocalc.com added the comment:
http://code.google.com/p/y2038/wiki/AmazingDiscoveries
AIX again
Merijn informs me that before year 0 AIX gets very, very slow.
--
___
Python tracker rep...@bugs.python.org
http
STINNER Victor victor.stin...@haypocalc.com added the comment:
Can you please attach your Makefile file?
In Makefile.pre.in, I see:
libpython$(VERSION).dylib: $(LIBRARY_OBJS)
VERSION should be 3.2, only LDVERSION is the VERSION + the ABI flags (eg.
3.2dm). And I don't see any usage
STINNER Victor victor.stin...@haypocalc.com added the comment:
Ah, there is also Mac/Makefile.in: attach also Mac/Makefile.
(and there is also Mac/PythonLauncher/Makefile.in, but I don't think that the
issue comes from this file)
((can it be related to python*-config program
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11222
___
___
Python
STINNER Victor victor.stin...@haypocalc.com added the comment:
@Georg: Is this issue a release blocker?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11222
STINNER Victor victor.stin...@haypocalc.com added the comment:
Ah ok, the issue comes from configure.in near line 779:
Darwin*)
LDLIBRARY='libpython$(LDVERSION).dylib'
BLDLIBRARY='-L. -lpython$(LDVERSION)'
RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11223
___
___
Python-bugs
STINNER Victor victor.stin...@haypocalc.com added the comment:
I will try with pdb or something.
You can also try to attach gdb to the running process: with
python-gdb.py, you have nice py-* commands.
Or if you don't have gdb7, you may try my faulthandler module: you will
have to modify
New submission from STINNER Victor victor.stin...@haypocalc.com:
len(ur'\u') == len(u'\u') == 1
len(ur'\U0010') == len(u'\U0010') == 1
but
len(ur'\n'), len(u'\n')
(2, 1)
len(ur'\x00'), len(u'\x00')
(4, 1)
\u and \U should not be interpreted in raw Unicode strings
STINNER Victor victor.stin...@haypocalc.com added the comment:
Python 2.x could not be changed, for compatibility reasons.
Well, it is not a bug because it is documented!
When an 'r' or 'R' prefix is used in conjunction with a 'u' or 'U' prefix,
then the \u and \U escape
STINNER Victor victor.stin...@haypocalc.com added the comment:
Here is what faulthandler reports when I trigger it as Python
is locked in test_socket:
...
File .../Lib/test/fork_wait.py, line 30 in f
faulthandler doesn't print the source code line (yet?). Here is the code:
class ForkWait
STINNER Victor victor.stin...@haypocalc.com added the comment:
Short answer:
In Python 3.2, « import héhé » doesn't work on Windows, but you can have
non-ASCII paths in sys.path.
Longer answer:
I fixed the import machinery to handle correctly non-ASCII characters in module
*paths
New submission from STINNER Victor victor.stin...@haypocalc.com:
There are 5 different usages of the bytes() constructor:
1) bytes(iterable_of_ints) - bytes
2) bytes(string, encoding[, errors]) - bytes
3) bytes(bytes_or_buffer) - immutable copy of bytes_or_buffer
4) bytes(memory_view) - bytes
5
STINNER Victor victor.stin...@haypocalc.com added the comment:
These are AFAIR the same.
So the docstring should also maybe be updated too:
$ python
help(bytes)
Help on class bytes in module builtins:
class bytes(object)
| bytes(iterable_of_ints) - bytes
| bytes(string, encoding
STINNER Victor victor.stin...@haypocalc.com added the comment:
The problem occurs on import (import bla reads bla.py), when Python tries to
create bla.pyc. The problem is that Python stores the timestamp as 4 bytes in
.pyc files, whereas time_t is 64 bits on Windows (at least on Windows XP
STINNER Victor victor.stin...@haypocalc.com added the comment:
To support bigger timestamps, we have to change the file format
of .pyc files.
write_compiled_module(), check_compiled_module() and other functions use the
marshal module to read/write binary file, but marshal has no function
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, this issue was already fixed by r87666 to fix the duplicate issue #8278.
--
nosy: +haypo
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, this issue was already fixed by r87666
... in py3k, and then merged into release31-maint (r87668) and release27-maint
(r87669).
--
___
Python tracker rep...@bugs.python.org
http
STINNER Victor victor.stin...@haypocalc.com added the comment:
Shouldn't module time be changed to use a cross-platform implementation
that uses a 64 bit time_t-like type? Apparently Perl 6 has made the
equivalent change.
The error occurs on time.gmtime(t): even if we use 64 bits time_t type
STINNER Victor victor.stin...@haypocalc.com added the comment:
It looks like your patch fixes #10829: you should add tests for that, you
can just reuse the tests of my patch (attached to #10829).
Sorry, but I think my patch doesn't fix #10829.
Ah ok, so don't add failing tests
New submission from STINNER Victor victor.stin...@haypocalc.com:
Issue #9003 added cafile and capath arguments to url_open(), but it is not
possible to reuse a SSLContext object (which would avoid to reload
certificates, CRL, etc.).
--
components: Library (Lib)
messages: 128779
nosy
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, my patch is incomplete: time2netscape() has the same issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5537
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, what if the trunked char* cannot be decoded correctly?
e.g. a tow-bytes character is divided in the middle?
Yes, but PyUnicode_FromFormatV() uses UTF-8 decoder with replace error handler,
and so the incomplete byte sequence
STINNER Victor victor.stin...@haypocalc.com added the comment:
No, I forgot to upload it...
--
keywords: +patch
Added file: http://bugs.python.org/file20785/cookiejar_datetime.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
If datetime.strftime() is not reliable, we should maybe fix it instead of using
a workaround?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5537
New submission from STINNER Victor victor.stin...@haypocalc.com:
While testing a patch fixing issue #7330, I found a bug in
PyUnicode_FromFormat() in the %V format: it decodes the byte string from
ISO-8859-1, whereas I would expect that the string is decodes from UTF-8, as
the %s format
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11246
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
Removed message: http://bugs.python.org/msg128975
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8650
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
Removed message: http://bugs.python.org/msg128976
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8651
STINNER Victor victor.stin...@haypocalc.com added the comment:
I removed Antoine's message because it was related to issue #8650.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8651
STINNER Victor victor.stin...@haypocalc.com added the comment:
Woops, I removed a duplicate message of Antoine. in this issue instead of
#8651. Removed message:
-
Fixed by r87729.
This only addresses the compress() and decompress() functions, but e.g. crc32()
and adler32() are also
STINNER Victor victor.stin...@haypocalc.com added the comment:
Confirmed on Python 3.2 (winxp).
The problem doesn't seem to exist on 3.1.3.
Can you try Python 3.1 with -u command line flag?
I changed Python 3.2 to always open all files in binary module, not only if -u
flag is used. I had
STINNER Victor victor.stin...@haypocalc.com added the comment:
+text = PyUnicode_FromFormat(b'repr=%V', 'abcdef', b'abcdef')
+self.assertEqual(text, 'repr=abcdef')
How do you know which argument is used? For example, you should use instead
'abc' and b'xyz'.
+text
STINNER Victor victor.stin...@haypocalc.com added the comment:
Fixed by r88476. I prefer to only change it in Python 3.3, so no backport.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
Fixed by r88478.
Not sure this can make it into stable branches.
I agree, I prefer to not touch stable releases.
--
resolution: - fixed
status: open - closed
___
Python tracker rep
STINNER Victor victor.stin...@haypocalc.com added the comment:
r88480 removes the filename variable: use gdb7+python-gdb.py or the
faulthandler module to get a Python backtrace.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
resolution: - fixed
status: open - closed
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11168
STINNER Victor victor.stin...@haypocalc.com added the comment:
Fixed in 3.3 (r88481).
Keep it open to backport it maybe to 3.2 later.
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10830
STINNER Victor victor.stin...@haypocalc.com added the comment:
Do adler32() and crc32() support length up to UINT32_MAX? Or should we maybe
limit the length to INT32_MAX?
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http
STINNER Victor victor.stin...@haypocalc.com added the comment:
Well, the main problem is that there are 3 different codes to parse the format
string, and each code is different... Attached patch factorizes the code:
create one subfunction parse_format_flags(). It fixes also this issue
STINNER Victor victor.stin...@haypocalc.com added the comment:
I started to commit some parts of the huge patch:
r88515: Mark PyWin_FindRegisteredModule() as private
r88516: Remove unused argument of _PyImport_GetDynLoadFunc()
r88517 (3.3), r88518 (3.2): document encoding used by import
STINNER Victor victor.stin...@haypocalc.com added the comment:
r88519: Mark _PyImport_FindBuiltin() argument as constant
r88520: Add PyModule_GetNameObject()
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3080
STINNER Victor victor.stin...@haypocalc.com added the comment:
Here is a patch to fix input() on Windows: strip also \r.
--
keywords: +patch
Added file: http://bugs.python.org/file20852/input_rn.patch
___
Python tracker rep...@bugs.python.org
http
STINNER Victor victor.stin...@haypocalc.com added the comment:
C:\Python32python
Python 3.2 ... on win32
import sys
for line in sys.stdin:
... print(repr(line))
...
hello
'hello\r\n'
^Z
Oh yes, I confirm that there is a second bug: sys.stdin doesn't
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file20852/input_rn.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11272
STINNER Victor victor.stin...@haypocalc.com added the comment:
Fixed in 3.3 (r88530) and 3.2 (r88531). Others versions are not affected.
Thanks Duncan Booth, I added tests based on your stdintests.py script. I used
directly stdin argument of Popen() instead of using cmd.exe to create the pipe
STINNER Victor victor.stin...@haypocalc.com added the comment:
Fixed in 3.2 too (r88532).
--
resolution: - fixed
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10830
STINNER Victor victor.stin...@haypocalc.com added the comment:
This new failure is perhaps related: (...) test_reprlib
Ah yes, yesterday, I tried to remember which test was impacted by the module
change, but all tests passed on Linux. Anyway, it's now fixed by r88533
STINNER Victor victor.stin...@haypocalc.com added the comment:
What is the problem with Python 3.2? It works correctly here:
$ cat bla.txt
bli
blo
bla
$ gzip bla.txt
$ ./python
Python 3.3a0 (unknown, Feb 23 2011, 13:03:50)
import gzip, io
f = io.TextIOWrapper(gzip.open(bla.txt.gz),encoding
STINNER Victor victor.stin...@haypocalc.com added the comment:
Yes, a clear definition of the minimum requirements for being wrapped
by TextIOWrapper sounds like a necessary thing to have
About that: is read1() argument mandatory or not?
In _pyio, BufferedIOBase.read1() argument is optional
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11303
___
___
Python-bugs
STINNER Victor victor.stin...@haypocalc.com added the comment:
I think that the normalization function in unicodeobject.c (only used for
internal functions) can skip any character different than a-z, A-Z and 0-9.
Something like:
import re
def normalize(name): return re.sub([^a-z0-9
STINNER Victor victor.stin...@haypocalc.com added the comment:
Patch implementing my suggestion.
--
Added file: http://bugs.python.org/file20875/aggressive_normalization.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file20875/aggressive_normalization.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11303
STINNER Victor victor.stin...@haypocalc.com added the comment:
Ooops, I attached the wrong patch. Here is the new fixed patch.
Without the patch:
import timeit
timeit.Timer('a'.encode('latin1')).timeit()
3.8540711402893066
timeit.Timer('a'.encode('latin-1')).timeit()
1.4946870803833008
STINNER Victor victor.stin...@haypocalc.com added the comment:
Python 3.2 has a _posixsubprocess: some parts of subprocess are implemented in
C. Can you try it?
Python 3.2 uses also pipe2(), if available, to avoid the extra fcntl(4,
F_GETFD)+fcntl(4, F_SETFD, FD_CLOEXEC).
I suppose
STINNER Victor victor.stin...@haypocalc.com added the comment:
That won't work, Victor, since it makes invalid encoding
names valid, e.g. 'utf(=)-8'.
.. but this *is* valid: ...
Ah yes, it's because of encodings.normalize_encoding(). It's funny: we have 3
functions to normalize an encoding
STINNER Victor victor.stin...@haypocalc.com added the comment:
more_aggressive_normalization.patch
Woops, normalizestring() comment points to itself.
normalize_encoding() might also points to the C implementations, at least in a
# comment
STINNER Victor victor.stin...@haypocalc.com added the comment:
r88586: Normalized the encoding names for Latin-1 and UTF-8 to
'latin-1' and 'utf-8' in the stdlib.
Why did you do that? We are trying to find a solution together, and you change
directly the code without any review. Your commit
STINNER Victor victor.stin...@haypocalc.com added the comment:
We should first implement the same algorithm of the 3 normalization functions
and add tests for them (at least for the function in normalization):
- normalize_encoding() in encodings: it doesn't convert to lowercase and keep
non
STINNER Victor victor.stin...@haypocalc.com added the comment:
For other spellings like utf8 or latin1, I wonder
if it would be useful to emit a warning/suggestion to use
the standard spelling.
Why do you want to emit a warning? utf8 is now as fast as utf-8
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11329
___
___
Python-bugs
STINNER Victor victor.stin...@haypocalc.com added the comment:
Can you write a patch for the documentation?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11329
New submission from STINNER Victor:
ctypes.util.find_library() fails to locate distorm64.so library
because it has no SONAME entry:
$ objdump -p -j .dynamic /usr/local/lib/libdistorm64.so
/usr/local/lib/libdistorm64.so: file format elf32-i386
(...)
Dynamic Section:
NEEDED libc.so.6
New submission from STINNER Victor:
ctypes doesn't support transparent conversion of double arguments.
Example code:
from ctypes import cdll, c_double
libm = cdll.LoadLibrary(libm.so)
sqrt = libm.sqrt
sqrt.argstype = (c_double,)
sqrt.restype = c_double
print sqrt(4.0)
I wrote a patch to fix
Changes by STINNER Victor:
Added file: http://bugs.python.org/file9468/libdistorm64.so
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2145
__
___
Python-bugs-list mailing list
STINNER Victor added the comment:
Ooops, I had a typo in my code! Argument types argument name
is argtypes and not argstype. But well, the ticket is still
valid :-) But it's more an enhancement than a bugfix ;-) So the right
code is :
from ctypes import cdll, c_double
libm = cdll.LoadLibrary
STINNER Victor added the comment:
« haypo, can you please give precise instructions on how to reproduce
this problem? »
Sure. Download http://www.ragestorm.net/distorm/dl.php?id=11
(distorm-pkg1.7.28.tar.bz2), go to build/linux/. Then compile it
with make and install it using make install
STINNER Victor victor.stin...@haypocalc.com added the comment:
This issue is directly related to issue #6697. The first problem is that the
builtin input() function doesn't check that _PyUnicode_AsString() result is not
NULL.
The second problem is that io.StringIO().encoding is None. I don't
STINNER Victor victor.stin...@haypocalc.com added the comment:
I found severe bugs (which may lead to security vulnerabilities) in audioop:
#7673. Nobody fixed these errors (but my issue contains a patch).
--
nosy: +haypo
___
Python tracker rep
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4653
___
___
Python-bugs
STINNER Victor victor.stin...@haypocalc.com added the comment:
See also #7673 (other crashers).
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8678
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
components: +Unicode
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8670
___
___
Python
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8670
___
___
Python-bugs
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8649
___
___
Python-bugs
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8648
___
___
Python-bugs
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8647
___
___
Python-bugs
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8646
___
___
Python-bugs
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8645
___
___
Python-bugs
STINNER Victor victor.stin...@haypocalc.com added the comment:
afaict, it needs backport to 2.7.
Right: r81135 (and r81137).
Blocked on 2.6 (it doesn't have the non-ASCII path test): r81139.
--
status: open - closed
___
Python tracker rep
STINNER Victor victor.stin...@haypocalc.com added the comment:
Support of characters outside the Unicode BMP (code 0x) is not complete
in narrow build (sizeof(Py_UNICODE) == 2) for Python2:
$ ./python
Python 2.7b2+ (trunk:81139M, May 13 2010, 18:45:37)
x=u'\U0001'
x[0], x[1]
(u
STINNER Victor victor.stin...@haypocalc.com added the comment:
Patch for Python3:
- Fix PyUnicode_AsWideChar() to support surrogates (Py_UNICODE: 2 bytes,
wchar_t: 4 bytes)
- u_set() of _ctypes uses PyUnicode_AsWideChar()
- add a test (skipped if sizeof(wchar_t) is smaller than 4 bytes
STINNER Victor victor.stin...@haypocalc.com added the comment:
Reference about OSX decomposition:
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html
Mac OS X source code:
http://www.opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/vfs/vfs_utfconv.c?txt
401 - 500 of 34965 matches
Mail list logo
