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
--
http://mail.python.org/mailman/listinfo/python-list
