On Tue, 13 Dec 2011 23:51:00 -0500
Terry Reedy 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.
___
Python-Dev mailing list
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 delegat
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.
> 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 Tue, Dec 13, 2011 at 2:55 AM, "Martin v. Löwis" 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 may vary by in
> (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
(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;
