Showing content from http://mail.python.org/pipermail/python-dev/attachments/20100406/8d0c603f/attachment.html below:
2010/4/6 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>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It will certainly. There's MUCH that can be optimized to let CPython squeeze more performance from static analysis (even a gross one) on locals.<br>
</blockquote>
<br></div>
But can the existing locals() function be implemented in<br>
the face of such optimisations?<br>
<br>
If it can, then a "locals view" object shouldn't be too much<br>
harder.<br>
<br>
If it can't, then you have already given up full CPython<br>
compatibility.<br>
<br>
-- <br><font color="#888888">
Greg</font></blockquote><div><br></div><div>A read-only locals view can be a good comprise, because at least the first example I showed can be approached well.<br></div><div><br></div><div>For the second example, there's no full compatibility with the current CPython implementation.</div>
<div><br></div><div>But implementations can change over the time: we can clearly define that on future CPython versions no assumptions must be made about locals "usage", and in general about instructions generation.</div>
<div>The most important thing is that the function f() does what is called to do: return the numeric constant 3.</div><div><br></div><div>This gives us the opportunity to schedule more efficient optimizations, without losing generality about the language (only some weird tricks will not be supported).</div>
<div><br></div><div>Cesare</div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4