<p dir="ltr">So code that depends on iterating through bytecode via HAS_ARG is going to break...</p>
<p dir="ltr">Darn it. :/</p>
<p dir="ltr">--<br>
Ryan<br>
[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.<br>
<a href="http://kirbyfan64.github.io/">http://kirbyfan64.github.io/</a></p>
<div class="gmail_quote">On Apr 13, 2016 4:44 PM, "Victor Stinner" <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mercredi 13 avril 2016, Ryan Gonzalez <<a href="mailto:rymg19@gmail.com" target="_blank">rymg19@gmail.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">What is the value of HAS_ARG going to be now?</p></blockquote><div><br></div><div>I asked Demur to keep HAS_ARG(). Not really for backward compatibility, but for the dis module: to keep a nice assembler. There are also debug traces in ceval.c which use it.</div><div><br></div><div>For ceval.c, we might use HAS_ARG() to micro-optimize oparg=0 (hardcode 0 rather than reading the bytecode) for operators with no argument. Or maybe it's completly useless :-)</div><div><br></div><div>Victor </div>
</blockquote></div>