<br><br><div><span class="gmail_quote">On 11/28/06, <b class="gmail_sendername">Talin</b> &lt;<a href="mailto:talin@acm.org">talin@acm.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Guido van Rossum wrote:<br>&gt; Some comments:<br>&gt;<br>&gt; - Talin's solution seems to require the definition of an awful lot of<br>&gt; new constants -- one per slot. And a lot of special-casing in the type<br>&gt; initialization code to handle them because there are so many different
<br>&gt; signatures.<br><br>Actually, I was thinking more on this, and I have a couple ideas on how<br>to avoid this, at least the part about the number of constants.<br><br>The first idea is that instead of having a constant per special method,
<br>simply use the regular name of the method, but have a method flag that<br>indicates that the method is &quot;special&quot;:<br><br>&nbsp;&nbsp;&nbsp;&nbsp; static PyMethodDef Noddy_methods[] = {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &quot;new&quot;, (PyCFunction)Noddy_new,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;METH_VARARGS | METH_SPECIAL, &quot;...&quot; },<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &quot;__init__&quot;, (PyCFunction)Noddy_init,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;METH_VARARGS | METH_SPECIAL, &quot;...&quot; },<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { NULL }&nbsp;&nbsp;/* Sentinel */
<br>&nbsp;&nbsp;&nbsp;&nbsp; };<br><br>One drawback here is that not all of the fields in PyTypeObject have<br>equivalent names; But there's no reason why we couldn't give them names,<br>especially if the names were not valid Python identifiers.
</blockquote><div><br>Coming up with equivalent names should definitely not be difficult.&nbsp; I honestly can't think of any that don't have a matching name off the top of my head short of tp_free/tp_dealloc.<br><br>One issue with this, though, will be the shifting of list and dict interfaces.&nbsp; They both have a __getitem__ method, but one expects only integers and one expects anything.&nbsp; Are you not going to optimize for that and just force lists to handle the type check and cast for every call?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The other drawback is that there's a greater chance of a misspelling,<br>but I don't see that as a serious problem - even the most cursory
<br>testing of the class should discover this, it's not like the resulting<br>bugs will be subtle and hard to find, IMHO.<br><br>You could go even further, and drop the &quot;special&quot; flag entirely, and<br>there's a compelling reason why you might want to do this: It means that
<br>now the VM gets to decide what methods are special and what methods<br>aren't. So if, for example, we decide in the future that '__unicode__'<br>needs to be sped up by putting it directly in the PyTypeObject, we can<br>
add a slot for it, and have all existing code magically work.</blockquote><div><br>That does help minimize backwards-compatibility issues.&nbsp; But it does make things implicit. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It does mean that the interpretation of the method table is a bit more<br>complex, but as long as you have a fast way of looking up the method<br>names, and determining whether to put each method into the class dict or<br>
to fill in a PyTypeObject slot, I don't think it would be too bad.<br><br>This is what Fredrik is saying about the advantage over C99<br>initialization, which only allows us to change the order of<br>initializers, not their names or meanings.
</blockquote><div><br>Ah, that is what you guys are getting at !&nbsp; That makes sense and is a compelling argument.<br><br>I think with this cleanup and a standardization on calling conventions (caller or callee checks for NULL arguments, who handles conversion to specific&nbsp; types, error return values, specifying ref stealing, etc.) this should go a long way to make extension modules much easier to work with.
<br><br>-Brett<br></div></div><br>