egreen added the comment:
The tests in TestEnUSCollation I added don't work for all encodings
(e.g. Asian ones, or ASCII). Now checked for encodings which are known
to work.
Found and fixed a bug (result not returned) in getpreferredencoding in
Lib/locale.py.
This test is skipped o
egreen added the comment:
I've added the tests.
I found that on Windows, strxfrm has been unavailable in py3k since
r61306, because of an omission in PC/pyconfig.h. (cf. patch)
In determining whether I should first test for the existence of strcoll
(or strxfrm) in the locale module, a
egreen added the comment:
All right.
The function strcoll also isn't tested (except for issue #3303). I'll
look into that one, too.
--
___
Python tracker
<http://bugs.python.
egreen added the comment:
Could someone triage this? And review my simple fix? I think it should
be a release blocker.
It seems to me to be a problem on all 64-bit non-Windows platforms, or
any platform if using UCS-4. The 4 high-order bytes of an 8-byte
Py_ssize_t variable are not
New submission from egreen :
The strxfrm function in the locale module can potentially raise a
MemoryError.
The failing malloc is in Modules/_localemodule.c, line 291.
This is because the variable n0 of type Py_ssize_t is passed to
PyArg_ParseTuple, which expects an int when PY_SSIZE_T_CLEAN
egreen added the comment:
Yes, it should indeed be a Py_ssize_t.
New patch.
--
Added file: http://bugs.python.org/file15050/bytes_maketrans_2.patch
___
Python tracker
<http://bugs.python.org/issue7
New submission from egreen :
The new maketrans static method in Python 3.1 segfaults when using byte
values > 127.
Reproduce: bytes.maketrans(bytes(range(256)), b'X' * 256)
Cause: _Py_bytes_maketrans in Objects/bytes_methods.c uses signed int as
array index.
Fix attached. A
egreen added the comment:
You are right. Guess I was being a little too dogmatic. :-)
I hadn't found those .pck files, because I was only looking for binary
files.
Here's a new patch proposal.
--
Added file: http://bugs.python.org/file14962/clean-grammar-pic
egreen added the comment:
These .pickle files aren't created by the tests themselves, but they do
show up after running 'make test', or more specifically after running
'./python Lib/test/regrtest.py -v test_lib2to3'.
This is because a grammar generated from a .txt gr
New submission from egreen :
make clean and make distclean don't remove the grammar pickles generated
by load_grammar in Lib/lib2to3/pgen2/driver.py
(Lib/lib2to3/Grammar3.2.0.alpha.0.pickle,
Lib/lib2to3/PatternGrammar3.2.0.alpha.0.pickle).
Proposed patch attached. It removes all *.pickle
egreen added the comment:
The problem is that the fileio struct in Modules/_io/fileio.c defines
the 2-bit seekable field as int.
>From the C99 standard, ยง6.7.2: for bit-fields, it is
implementation-defined whether the specifier int designates the same
type as signed int or the same type
New submission from egreen :
in Doc/c-api/bytearray.rst:
PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
should be:
int PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
as per Include/bytearrayobject.h
--
assignee: georg.brandl
components
New submission from egreen :
In documentation (c-api/buffer.html):
void PyBuffer_Release(PyObject *obj, Py_buffer *view)
should be:
void PyBuffer_Release(Py_buffer *view)
(as per Include/abstract.h)
--
assignee: georg.brandl
components: Documentation
messages: 92165
nosy: egreen
13 matches
Mail list logo
