2010/10/24 Greg Ewing <span dir="ltr"><<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Cesare Di Mauro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that having max 255 args and 255 kwargs is a good and reasonable limit which we can live on, and helps the virtual machine implementation<br>
</blockquote>
<br></div>
Is there any corresponding limit to the number of arguments to<br> tuple and dict constructor?</blockquote><div><br></div><div>AFAIK there's no such limit. However, I'll use BUILD_TUPLE and BUILD_MAP opcodes for such purpose, because they are faster.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If not, the limit could perhaps be<br>
circumvented without changing the VM by having the compiler<br>
convert calls with large numbers of args into code that builds<br>
an appropriate tuple and dict and makes a *args/**kwds call.<br>
<br>
-- <br><font color="#888888">
Greg</font></blockquote><div><br></div><div>I greatly prefer this solution, but it's a bit more complicated when there are *arg and/or **kwargs special arguments.</div><div><br></div><div>If we have > 255 args and *args is defined, we need to:</div>
<div>1) emit BUILD_TUPLE after pushed the regular arguments</div><div>2) emit LOAD_GLOBAL("tuple")</div><div>3) push *args</div><div>4) emit CALL_FUNCTION(1) to convert *args to a tuple</div><div>5) emit BINARY_ADD to append *args to the regular arguments</div>
<div>6) emit CALL_FUNCTION_VAR</div><div><br></div><div><div>If we have > 255 kwargs and **kwargs defined, we need to:</div><div>1) emit BUILD_MAP after pushed the regular keyword arguments</div><div>2) emit LOAD_ATTR("update")</div>
<div>3) push **kwargs</div><div>4) emit CALL_FUNCTION(1) to update the regular keyword arguments with the ones in **kwargs</div><div>5) emit CALL_FUNCTION_KW</div><div><br></div><div>And, finally, combining all the above in the worst case.<br>
</div><div><br></div><div>But, as I said, I prefer this one to handle "complex" cases instead of changing the VM slowing the common ones.</div><div><br></div><div>Cesare</div></div>