<br><div><span class="gmail_quote">On 5/14/06, <b class="gmail_sendername">"Martin v. Löwis"</b> <<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Georg Brandl wrote:<br>>> Right. At least, not with changing structmember.[ch].<br>><br>> Did you mean "without"?<br><br>Oops, right.<br><br>> Can I submit a patch?<br><br>I personally don't mind having more types added to structmember,
<br>so I'm +0 on adding Py_ssize_t to the list of types supported.<br>I wonder what the specific application is that you have in mind,<br>though.</blockquote><div><br>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.)
<br></div></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!