...

...

/* PyBufferProcs contains bf_getcharbuffer */ #define Py_TPFLAGS_HAVE_GETCHARBUFFER (1L<<0) + #define Py_TPFLAGS_HAVE_SEQUENCE_IN (1L<<1)

If this flag is going to be defined, then it needs a comment about it. The above code seems to imply that HAVE_SEQUENCE_IN is related to the PyBufferProces.

Good catch!

...

...

#define Py_TPFLAGS_DEFAULT (Py_TPFLAGS_HAVE_GETCHARBUFFER)

I would modify this to include Py_TPFLAGS_HAVE_SEQUENCE_IN by default. The flag means that the code knows that the sq_contains field exists; not that this particular object has a non-NULL value in it. So it can always be on in code compiled with this version of the header file.

Guido: adding new flags is *only* necessary when you want to avoid changes in the PYTHON_API_VERSION. If the API has already changed between 1.5 and 1.6, then PYTHON_API_VERSION should be bumped, and this new tp_flags value is not necessary.

In fact, when you bump the VERSION, it can even be argued that these specific flags get obsoleted (since an extension must be compiled with the new VERSION to be properly loaded, which makes it pick up the new slot).

So... I'd pose this question to you, Guido: will the API version be bumped for Python 1.6? If so, then we have some potential cleanup that can occur.

I'd like to keep the API version unchanged from 1.5.2, if at all possible. That will depend on how we end up doing new coercions and rich comparisons.

(note: tp_flags is not *reserved* for slot extensions; it is simply that we haven't discovered any other flags to put in there yet)

Indeed.

...

...

+ 0, /* tp_as_buffer */ + Py_TPFLAGS_HAVE_SEQUENCE_IN, /* tp_flags */

This could be Py_TPFLAGS_DEFAULT.

I'd rephrase as *should*.

Remember: the flag bits (as used today) are to determine whether a slot exists -- in lieu of changing the PYTHON_API_VERSION. Once you compile under the new definition of PyBufferProcs or PySequenceMethods, then the slots will definitely exist; therefore, Py_TPFLAGS_DEFAULT should be used.

Yeah, sure. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

...

/* PyBufferProcs contains bf_getcharbuffer */ #define Py_TPFLAGS_HAVE_GETCHARBUFFER (1L<<0) + #define Py_TPFLAGS_HAVE_SEQUENCE_IN (1L<<1)

If this flag is going to be defined, then it needs a comment about it. The above code seems to imply that HAVE_SEQUENCE_IN is related to the PyBufferProces.

Good catch!

...

...

#define Py_TPFLAGS_DEFAULT (Py_TPFLAGS_HAVE_GETCHARBUFFER)

I would modify this to include Py_TPFLAGS_HAVE_SEQUENCE_IN by default. The flag means that the code knows that the sq_contains field exists; not that this particular object has a non-NULL value in it. So it can always be on in code compiled with this version of the header file.

Guido: adding new flags is *only* necessary when you want to avoid changes in the PYTHON_API_VERSION. If the API has already changed between 1.5 and 1.6, then PYTHON_API_VERSION should be bumped, and this new tp_flags value is not necessary.

In fact, when you bump the VERSION, it can even be argued that these specific flags get obsoleted (since an extension must be compiled with the new VERSION to be properly loaded, which makes it pick up the new slot).

So... I'd pose this question to you, Guido: will the API version be bumped for Python 1.6? If so, then we have some potential cleanup that can occur.

I'd like to keep the API version unchanged from 1.5.2, if at all possible. That will depend on how we end up doing new coercions and rich comparisons.

(note: tp_flags is not *reserved* for slot extensions; it is simply that we haven't discovered any other flags to put in there yet)

Indeed.

...

...

+ 0, /* tp_as_buffer */ + Py_TPFLAGS_HAVE_SEQUENCE_IN, /* tp_flags */

This could be Py_TPFLAGS_DEFAULT.

I'd rephrase as *should*.

Remember: the flag bits (as used today) are to determine whether a slot exists -- in lieu of changing the PYTHON_API_VERSION. Once you compile under the new definition of PyBufferProcs or PySequenceMethods, then the slots will definitely exist; therefore, Py_TPFLAGS_DEFAULT should be used.

Yeah, sure. --Guido van Rossum (home page: http://www.python.org/~guido/)