On Tue, 10 Jun 2014 19:07:40 +1000, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 Jun 2014 18:41, "Paul Moore" <p.f.mo...@gmail.com> wrote: > > > > On 10 June 2014 08:36, Nick Coghlan <ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
