Python 3: exec arg 1

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sun Jan 18 10:36:35 EST 2009


On Sun, 18 Jan 2009 14:36:15 +0000, Alan G Isaac wrote:

> Well, that does not really answer my question, imo. I do not much care
> about the disappearance of ``execfile``. I was asking, why is it a
> **good thing** that ``exec`` does not accept a TextIOWrapper? 


I'm not sure if this is a stupid question or not, but what's a 
TextIOWrapper? In the example you give:

exec(open(fname))

the argument to exec -- open(fname) -- is a file object:

>>> type(open('hello.py'))
<type 'file'>


BTW, exec is a statement. The brackets there are totally superfluous. You 
can, and should, write: 

exec open(fname)


> Or is it just not implemented yet?
> What is the gain from this particular backwards incompatibility (in the
> sense that ``exec(open(fname))`` no longer works)?

Simplicity of implementation?


> Context: I used to be able to tell students they could run their scripts
> from the interpreter prompt with ``execfile(fname)``.  I expected to be
> able to tell them to ``exec( open(fname) )``, which worked in Python 2. 
> Now instead it is ``exec( open(filename).read() )`` which is a bit more
> mysterious to a newbie.  (Note: I teach economics, not computer
> science.) 

Why don't you give your students a site.py module containing

def execfile(fname):
    exec open(fname).read()

and tell them to do "from site import execfile"?

If you control the environment they are running their programs on (school 
computers?) then you can put a startup file in their path and have 
execfile imported automatically.


-- 
Steven



More information about the Python-list mailing list