[Python-Dev] Criticism of execfile() removal in Python3 (original) (raw)

R. David Murray rdmurray at bitdance.com
Tue Jun 10 15:05:55 CEST 2014

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 runpath 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 runpath.

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

More information about the Python-Dev mailing list