Issue5

Title execfile cannot be used as an expression
Priority bug Status resolved
Superseder Nosy List 1989lzhh, kayhayen
Assigned To kayhayen Keywords compiler_crash, help_wanted

Created on 2011-11-04.05:13:05 by 1989lzhh, last changed by kayhayen.

Messages
msg685 (view) Author: kayhayen Date: 2014-06-23.07:38:41
Just released as part of 0.5.2
msg659 (view) Author: kayhayen Date: 2014-05-17.07:24:00
This is finally being resolved. The new code generation doesn't mind it anymore,
so Nuitka 0.5.2pre5 is no longer affected. A test of it was be added now to the
"factory" branch.
msg427 (view) Author: kayhayen Date: 2013-09-25.09:08:11
Sorry, seems this was subjected to spam.
msg20 (view) Author: kayhayen Date: 2011-11-07.23:32:21
Pushed the idea from my last comment. The compilation of "setup.py" now works 
fine.
msg18 (view) Author: kayhayen Date: 2011-11-07.19:12:27
I had an idea, while posting the list. How about using the new execfile builtin 
node only for non classes, and for classes the old approach with exec builtin 
node.

That way, all code we have should work now. I will give it a try for the 0.3.15 
release cycle.
msg15 (view) Author: kayhayen Date: 2011-11-05.18:36:05
With what I pushed to develop, there is now execfile builtin node, that could be 
used, if we could create code for it that works for classes too, i.e. a writable 
locals() mapping object.

I tagged it as help_wanted, because somebody could step up and do it.
msg12 (view) Author: kayhayen Date: 2011-11-05.09:15:36
My last note should be ignored. It turns out that it is perfect, except when 
execfile() is in a class, then it does modify the locals, and subsequently the 
class, something which one CPython test actually covers.

As a way forward, a mapping could be provided that takes it on itself to write 
to the correct local variable. The problem is, what happens with surviving 
"locals" references, after return. This object would need to be able to detect 
that situation.

If we had that, it would be also a way for generally cleaner code without a copy 
back and forth to a dict for exec either.

From the requirements, it seems execfile() is between exec and eval. It less 
often updates the locals, namely not for functions, but only for classes.

The bad thing code generation wise is that we currently can only have execfile() 
become an expression, which means that it cannot execute the copy-back like our 
current exec code does.

A mapping is allowed to exec/eval/execfile for locals.

I am also considering simple workarounds. I naively did:

print execfile( tmp_file )

as a test, and in this case, it's not so easy to optimize it way. It could be 
done for:

return execfile( tmp_file )

which is contained in the:

lambda : execfile( tmp_file )

you got there.
msg10 (view) Author: kayhayen Date: 2011-11-04.22:03:55
Instead of doing it with "exec", the code now will do it with "eval" and a 
changed compilation mode.

One drawback is that the filename gets lost currently, but that won't matter
at all I think. To track that, I am going to put it to closed provisory. Part
of hotfix 0.3.11b, tests are running right now.

The remaining issue will be to use a temporary value for the filename 
expression and provide it to both the COMPILE_CODE and to the OPEN
for getting the contents. I am leaving it unassigned, because I do not
intend to do it.
msg6 (view) Author: kayhayen Date: 2011-11-04.07:44:02
The issue is that "execfile( filename )" builtin becomes replaces with "exec 
open(filename)", but the later is a statement whereas the first is an 
expression.

Adding a source reference to the assertion, I get:

  File 
"/home/hayen/private/Py2C/nuitka/transform/optimizations/OptimizeBuiltins.py", 
line 295, in execfile_extractor
    assert node.parent.isStatementExpressionOnly(), node.getSourceReference()
AssertionError: <SourceCodeReference to /usr/lib/python2.7/dist-
packages/setuptools/sandbox.py:30>

The code there looks like this:

lambda: execfile(
    "setup.py",
    {'__file__':setup_script, '__name__':'__main__'}
)

We need to have a node that is an "exec" but an expression. This would be 
"eval", but with different flags to use. Needs structural changes.
History
Date User Action Args
2014-06-23 07:38:41kayhayensetstatus: testing -> resolved
messages: + msg685
2014-05-17 07:24:00kayhayensetstatus: chatting -> testing
assignedto: kayhayen
messages: + msg659
nosy: + kayhayen
title: execfile cannot be used as an expression (help wanted) -> execfile cannot be used as an expression
2013-09-25 09:08:11kayhayensetmessages: + msg427
title: NewInterface -> execfile cannot be used as an expression (help wanted)
2013-09-25 09:07:12kayhayensetmessages: - msg422
2013-08-26 14:51:35dryhorse82setstatus: done-cbb -> chatting
messages: + msg422
title: execfile cannot be used as an expression (help wanted) -> NewInterface
2011-11-07 23:32:21kayhayensetstatus: deferred -> done-cbb
messages: + msg20
2011-11-07 19:12:27kayhayensetstatus: chatting -> deferred
messages: + msg18
2011-11-05 18:36:05kayhayensetmessages: + msg15
2011-11-05 16:44:24kayhayensetkeyword: + help_wanted
title: when I use Nuitka-0.3.13 to compile the setup.py under Nuitka-0.3.13 fold with the flag --deep.it fails. -> execfile cannot be used as an expression (help wanted)
2011-11-05 09:15:36kayhayensetstatus: done-cbb -> chatting
messages: + msg12
2011-11-04 22:03:55kayhayensetstatus: in-progress -> done-cbb
assignedto: 1989lzhh -> (no value)
messages: + msg10
2011-11-04 07:44:02kayhayensetmessages: + msg6
2011-11-04 07:38:31kayhayensetstatus: unread -> in-progress
assignedto: 1989lzhh
keyword: + compiler_crash
nosy: + 1989lzhh
2011-11-04 05:13:051989lzhhcreate