<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 11:04 AM, Georg Brandl <span dir="ltr"><<a href="mailto:g.brandl@gmx.net" target="_blank">g.brandl@gmx.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Am 05.02.2014 14:52, schrieb "Martin v. Löwis":<br>


<div class="im">> Am 03.02.14 15:43, schrieb Larry Hastings:<br>
>> A: We create a PyMethodDefEx structure with an extra field: "const char<br>
>> *signature".  We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to<br>
>> the flags, indicating that this is an extended structure.  When<br>
>> iterating over the PyMethodDefs, we know how far to advance the pointer<br>
>> based on this flag.<br>
>><br>
>> B: Same as A, but we add three unused pointers (void *reserved1 etc) to<br>
>> PyMethodDefEx to give us some room to grow.<br>
>><br>
>> C: Same as A, but we add two fields to PyMethodDefEx.  The second new<br>
>> field identifies the "version" of the structure, telling us its size<br>
>> somehow.  Like the lStructSize field of the OPENFILENAME structure in<br>
>> Win32.  I suspect YAGNI.<br>
><br>
> D: Add a new type slot for method signatures. This would be a<br>
> tp_signature field, along with a new slot id Py_tp_signature. The<br>
> signature field itself could be<br>
><br>
> struct PyMethodSignature {<br>
>    char *method_name;<br>
>    char *method_signature;<br>
> };<br>
<br>
</div>Mostly unrelated question while seeing the "char *" here: do we (or do we<br>
want to) support non-ASCII names for functions implemented in C?<br></blockquote><div><br></div><div>Extension modules names being non-ASCII being discussed in <a href="http://bugs.python.org/issue20485">http://bugs.python.org/issue20485</a> <br>

</div></div></div></div>