On Tue, 10 Jun 2014 19:07:40 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote: > On 10 Jun 2014 18:41, "Paul Moore" <p.f.moore at gmail.com> wrote: > > > > On 10 June 2014 08:36, Nick Coghlan <ncoghlan at gmail.com> wrote: > > > The standard implementation of run_path reads the whole file into > > > memory, but MicroPython would be free to optimise that and do > > > statement by statement execution instead (while that will pose some > > > challenges in terms of handling encoding cookies, future imports, etc > > > correctly, it's certainly feasible). > > > > ... and if they did optimise that way, I would imagine that the patch > > would be a useful contribution back to the core Python stdlib, rather > > than remaining a MicroPython-specific optimisation. > > 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. > > 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. If it is a separate API, it seems like there's no reason it couldn't be contributed back to CPython. There might be other contexts in which low memory would be the right tradeoff. Although, if key bits end up working at the C level, "contributing back" might require writing separate C for CPython, so that might not happen. --David
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