<p dir="ltr"><br>
On 10 Jun 2014 18:41, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 10 June 2014 08:36, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> > The standard implementation of run_path reads the whole file into<br>
> > memory, but MicroPython would be free to optimise that and do<br>
> > statement by statement execution instead (while that will pose some<br>
> > challenges in terms of handling encoding cookies, future imports, etc<br>
> > correctly, it's certainly feasible).<br>
><br>
> ... and if they did optimise that way, I would imagine that the patch<br>
> would be a useful contribution back to the core Python stdlib, rather<br>
> than remaining a MicroPython-specific optimisation.</p>
<p dir="ltr">I believe it's a space/speed trade-off, so I'd be surprised if it made sense for CPython in general. There are also some behavioural differences when it comes to handling syntax errors.</p>
<p dir="ltr">Now that I think about the idea a bit more, if the MicroPython folks can get a low memory usage incremental file execution model working, the semantic differences mean it would likely make the most sense as a separate API in runpy, rather than as an implicit change to run_path.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Paul<br>
</p>