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

Paul Sokolovsky pmiscml at gmail.com
Sat Jun 14 22:52:15 CEST 2014

Hello,

On Tue, 10 Jun 2014 17:36:02 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:

On 10 June 2014 12:23, Paul Sokolovsky <pmiscml at gmail.com> wrote: > 1. It hampers interactive mode - instead of short and easy to type > execfile("file.py") one needs to use exec(open("file.py").read()). > I'm sure that's not going to bother a lot of people - after all, the > easiest way to execute a Python file is to drop back to shell and > restart python with file name, using all wonders of tab completion. > But now imagine that Python interpreter runs on bare hardware, and > its REPL is the only shell. That's exactly what we have with > MicroPython's Cortex-M port. But it's not really > MicroPython-specific, there's CPython port to baremetal either - > http://www.pycorn.org/ .

https://docs.python.org/3/library/runpy.html#runpy.runpath import runpy fileglobals = runpy.runpath("file.py")

Thanks, it's the most productive response surely. So, at least there's alternative to removed execfile(). Unfortunately, I don't think it's good alternative to execfile() in all respects. It clearly provides API for that functionality, but is that solution of least surprise and is it actually known by users at all (to be useful for them)?

Googling for "execfile python 3", top 3 hits I see are stackoverflow questions, none of which mentions runpy. So, people either don't consider it viable alternative to execfile, or don't know about it at all (my guess it's the latter).

Like with previous discussion, its meaning goes beyond just Python realm - there's competition all around. And internets bring funny examples, like for example http://www.red-lang.org/p/contributions.html (scroll down to diagram, or here's direct link: http://3.bp.blogspot.com/-xhOP35Dm99w/UuXFKgY2dlI/AAAAAAAAAGA/YQu98_pPDjw/s1600/reichart-abstraction-diagram.png) So, didn't you know that Ruby can be used for OS-level development, and Python can't? Or that JavaScript DSL capabilities are better than Python's (that's taking into account that JavaScript DSL capabilities are represented by JSON, whose creators were so arrogant as to disallow even usage of comments in it).

So, now suppose there's a discussion of how good different languages are for interactive usage (out of the box apparently). It would be a little hard to defend claim that Python is excellent interactive language, if its latest series got -1 on that scale, by removing feature which may be indispensable at times. Knowing that, one subconsciously may start to wonder if Ruby or JavaScript are doing it (in wide sense) better than Python.

-- Best regards, Paul mailto:pmiscml at gmail.com

More information about the Python-Dev mailing list