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

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


More information about the Python-Dev mailing list