Le mardi 13 décembre 2011 02:09:02 Jim Jewett a écrit :
(3) I would feel much less nervous if the remaining 4 values of
PyUnicode_Kind were explicitly reserved, and the macros raised an
error when they showed up. (Better still would be to allow other
values, and to have the macros delegate
On Tue, 13 Dec 2011 23:51:00 -0500
Terry Reedy tjre...@udel.edu wrote:
So by analogy, reserved type value would be ignored, neither corrupting
data or raising errors, until put in use.
That simply doesn't make sense.
Regards
Antoine.
___
On Tue, Dec 13, 2011 at 2:55 AM, Martin v. Löwis mar...@v.loewis.de wrote:
(1) Why is PyObject_HEAD used instead of PyObject_VAR_HEAD?
The unicode object is not a var object. In a var object, tp_itemsize
gives the element size, which is not possible for unicode objects,
since the itemsize
Any chance of adding the rationale to the code?
I'm really short of time right now, so you need to find somebody
else to make such a change.
I am willing to believe that requests for a wchar_t (or utf-8 or
System Locale charset) representation are common enough to justify
caching the data
On 12/13/2011 7:01 PM, Martin v. Löwis wrote:
What I'm asking is that
(1) The other values be documented as reserved, rather than as illegal.
How is that different?
(2) The macros produce an error rather than silently corrupting data.
In debug mode, or release mode? -1 on release mode.
(see http://www.python.org/dev/peps/pep-0393/ and
http://hg.python.org/cpython/file/6f097ff9ac04/Include/unicodeobject.h
)
typedef struct {
PyObject_HEAD
Py_ssize_t length;
Py_hash_t hash;
struct {
unsigned int interned:2;
(1) Why is PyObject_HEAD used instead of PyObject_VAR_HEAD? It is
because of the names (.length vs .size), or a holdover from when
unicode (as opposed to str) did not expect to be compact, or is there
a deeper reason?
The unicode object is not a var object. In a var object, tp_itemsize
