On 5/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
I ended up needing T_SSIZE_T or T_SIZE_T (I forget which) in my first attempt to fully Py_ssize-t-ify ctypes (but I was learning a lot about ctypes at the same time, and I ended up breaking a lot of stuff.) I'm now not sure whether it's really necessary for ctypes, but it was trivial to add, not to mention symmetric and completely logical. However, I also have a C extension of my own that exposes something quite like 'length' as an attribute, and it really ought to be a Py_ssize_t struct member (instead of the long it is now.)
Georg Brandl wrote:
>> Right. At least, not with changing structmember.[ch].
>
> Did you mean "without"?
Oops, right.
> Can I submit a patch?
I personally don't mind having more types added to structmember,
so I'm +0 on adding Py_ssize_t to the list of types supported.
I wonder what the specific application is that you have in mind,
though.
I ended up needing T_SSIZE_T or T_SIZE_T (I forget which) in my first attempt to fully Py_ssize-t-ify ctypes (but I was learning a lot about ctypes at the same time, and I ended up breaking a lot of stuff.) I'm now not sure whether it's really necessary for ctypes, but it was trivial to add, not to mention symmetric and completely logical. However, I also have a C extension of my own that exposes something quite like 'length' as an attribute, and it really ought to be a Py_ssize_t struct member (instead of the long it is now.)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
