structmember.h lacks a 'T_SIZET' define in order to properly support
struct fields of type 'size_t'  within PyMemberDef.

If this feature request is accepted, I can provide the patches. 

For 2.7, It would be nice to do:

#define T_SIZET      20      /* size_t */

However, this value is already used in 3.0 for 'T_NONE'. Perhaps T_NONE
should be backported to 2.7?

To avoid future merge conflicts, I would vote for this definition:

#define T_SIZET      21      /* size_t */

Do we really want size_t or rather Py_ssize_t?

In 2.6 and 3.0, we already have 'Py_ssize_t', see 'T_PYSSIZET'
definition on Include/structmember.h. I'm asking for 'size_t' support.

> In 2.6 and 3.0, we already have 'Py_ssize_t', see 'T_PYSSIZET'
> definition on Include/structmember.h. I'm asking for 'size_t' support.

Oops, sorry for the noise then.

> If this feature request is accepted, I can provide the patches.

Well, that's not how things work:  there isn't really a mechanism for 
'accepting' a feature request.  Even if there were, that wouldn't 
guarantee acceptance of a patch for that feature request.

For what it's worth, I think that there's a good chance that a well-
written patch for this feature request would be accepted:  it seems like a 
potentially useful addition, and I can't immediately see why it would be 
objectionable or controversial, but I haven't looked at the issue very 
closely.  I'd suggest that provided you don't get any negative feedback 
from the python-dev thread or from the comments in this issue in the next 
few days, then it's probably worth working on a patch.

I'd also be happy to review such a patch if/when it's ready.

msg81942 states "structmember.h lacks a 'T_SIZET' define in order to properly support struct fields of type 'size_t'  within PyMemberDef."  As we have managed without this feature for the last five years do we really need it now?  What do we gain by implementing this?