py--execute-base-intern: Text is read-only

Asked by chris

Environment:

Aquamacs 3.2 GNU Emacs 24.4.51.2
python-mode Version: 20160620.33 (elpa)
Python 2.7.12 |Continuum Analytics, Inc.| (default, Jun 29 2016, 11:09:23)

Running python locally on local files, no tramp-mode involved.

Symptoms:

I have basically never seen python-mode actually work. Instead I See two different behaviors, neither of them good.

When I invoke 'M-x py-execute-line' to send a single line of innocuous python code to the interpreter, the python interpreter starts in another window, the minbuffer shows "Wrote /var/folders/n1/tt80zjxj3sg3r4syxrnsd2n80000gn/T/python-22765Ls2.py", but nothing gets sent to the interpreter.

If instead of invoke Python -> Send -> Execute Line, I get the message "Wrote ..." with the temporary filename, and then the the interpreter frame belches up,

>>> Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: '/var/folders/n1/tt80zjxj3sg3r4syxrnsd2n80000gn/T//python-22765kUY.py'

Any suggestions for debugging this?
I have checked that the directory /var/folders/n1/tt80zjxj3sg3r4syxrnsd2n80000gn/T exists and is writable. While there are some files there, the temporary python file is not.

Question information

Language:
English Edit question
Status:
Answered
For:
python-mode.el Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
chris (cswarth) said :
#1

Now I know why this is happening. Part of the answer is the innocuous line of python I was sending to the interpreter. I didn't realize the interpreter would not echo what was being sent, and the line I send produced no output. So 'M-x py-send-line' is working as expected.

Python -> Send -> Execute line still fails, but I think it because the temporary file is being delete before the interpreter has a chance to run. If I take out the call to 'py-delete-temporary' in 'py--close-execution', all is well and Python -> Send -> Execute line works as expected.

I'll try extending the wait time '(sit-for 0.1 t)' in 'py--execute-buffer-finally' and I bet that will fix the problem.

Revision history for this message
Andreas Roehler (a-roehler) said :
#2

Thanks. Created a bug-report.

Revision history for this message
Andreas Roehler (a-roehler) said :
#3

Should be fixed in trunk. Thanks reporting.

Can you help with this problem?

Provide an answer of your own, or ask chris for more information if necessary.

To post a message you must log in.