I've recently come back to a project having had to stop for about 6 months, and after reinstalling my operating system and coming back to it I'm having all kinds of crazy things happen. I made sure to install the same version(2.6) of python that I was using before.
It started by giving me strange tkinter error that I hadn't had trouble with before, the program is relatively simple and the 2 or 3 bugs that were left when i quit, I had documented and weren't related to the interface.
Things got even weirder when the same error would pop up even after I had removed the offending section of code. In fact, the traceback pointed to a line that didn't even exist in the module it was referencing, eg: line 262 when the module was only 200 lines long.
After just starting a completely new file for the main module and copy/pasting it finally recognized that the offending code was gone and I stopped getting the error only to find that any updates to the code I made in another module didn't show up when I restarted the program through the shell. (I didn't forget to save.) After fiddling with this, of course, the old interface error came back, only in a different section of code that had been working previously.
In fact, if I revert back to the files I had six months ago, the program works fine. As soon as I change anything in the main module, however, the interface bug comes back.
Here's the original error:
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
File "C:\PyStuff\interface.py", line 202, in dispOne
__main__.top.destroy()
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1938, in destroy
self.tk.call('destroy', self._w)
TclError: can't invoke "destroy" command: application has been destroyed
I'm guessing something else is going on here other than my own poor programming. Anyone have any ideas?
Edit: Thinking back, I believe I read something about it being a bad idea to run Tkinter programs through IDLE's shell, and it appears, at least, that the TclError has vanished if I instead start the main module by double clicking the .pyc file. Perhaps my problems were just a combination of that plus the timestamp/PYTHONPATH issues mentioned below by Chris Atlee and Vlad?
I've had something similar happen. The cause for my problems was that my source control software (hg) was setting the date of files to a date in the past. Because of this, python chose to use previously generated .pyc files which had newer timestamps.
The solution was to delete all the .pyc files before testing the code.
Check your PYTHON_PATH variable, you probably have an older version of the file.
Also start your python interpreter and type the following commands to check the path:
import sys
print sys.path
Take a careful look at the output and make sure you don't have any old directories sitting there.
Related
I have encountered an issue where I have a file in Onedrive that I am not able to move. I have determined that, despite it saying that the action cant be completed because the folder or file is open in another program, it is not being used by another program.
I have come to this conclusion by using resource monitor to check which apps are using the folder. There are none besides file explorer.
Context as it's probably important:
The reason why this has happened is that i deleted a python venv in the file directory, resulting in my VS Code interpreter breaking. I have restored this venv file but the issue still has not been fixed. According to this post, it is the result of workspace links, however, I have never once used workspaces. The general idea that a file WITHIN that unmovable directory could be the reason though, and as a result, is possibly why this issue may be occuring. What does not make sense is why it is still happening even without VS Code running or any service connections being made as evident through resource monitor
Another thing to note is that the folder has not completely synced, however, based on past experience, this should not be an issue.
I successfully moved the file via terminal, however the issue still remains about why i could not simply move the file with file explorer.
I am brand new to python and programming more generally so 1) I'm an ignorant noob and I apologize and 2) I'm really just using IDLE for very basic learning. I'm running python 3.7.6 on Mac OS Catalina 10.15.3
My problem is bizarre: When I go to save a new .py file, IDLE freezes and becomes unresponsive. I'll hit CMD+S on a new/'Untitled.py' file, the save folder will pop open, and I can name the new file/navigate folders, but once I hit "Save", the program freezes with the save folder still open, except now the Save/Cancel buttons are greyed out and the entire application becomes unresponsive. My only recourse is to Force Quit and relaunch IDLE, and the new file I was trying to save never saved. You can imagine how fun this is.
What's weird is it doesn't happen every time. If I open IDLE, open a new file and very quickly/immediately save (which I try to do by default), then the file will save. Once I've saved it once, I have no problems saving the existing file as I work on it. That is, the issue is only with the creation/save of new files. I'm also not sure why sometimes I can Save a new file and other times (especially if IDLE has been open for a while) it crashes.
To be clear: I can open files, save existing files, and run programs I've written without incident. I am not getting any warnings, crash notifications, or notices of any kind that even acknowledge that IDLE is acting up.
I had 3.8, which I replaced for 3.7.6 thinking a more stable version might solve my problems, but no dice. I only have python 3.7.6 on my computer: No python 2, nothing else. I have no idea what's going on but this is super frustrating and I just want to be able to learn Python without these weird roadblocks.
Please help!
I've also had this problem, and what I did was change the location of where the file would save. I suggest trying this to help.
I'd suggest reinstalling python idle (your programs will be saved). If this doesn't work then maybe it has something to do with your security on the mac.
I had the same problem, and as Aadi suggested, I was able to fix it by changing the location of where the file was saved. Possibly, this relates to very long paths, at least in Windows 10.
The path that didn't work was 114 characters long. The path that did work was 93 characters long. The paths are the same up to character 80 and use underscore (_) but no unusual characters.
You don't have to make/save python files in IDLE. You can open any text editor, type the code, and save as name.py. Then you can open that in IDLE. I would use that for now.
I also came across with same issue, this is only issue of currupt file,please delete recent python IDLE file that you have created,this will definately work
I have PyCharm Professional Edition 3.5 5.0 configured to
use IPython when possible
and in my Run/Debug Configurations I set
show interpreter afterwards
I use the interactive Interpreter a lot and I really like IPython, but there are some things that I don't like about the way this is handled in PyCharm:
any input() in my programs return empty strings.
Additionally, when an error occurs I can't interact with the Program anymore. (you can when you run a Python program with the -i flag)
There is a lot of space between the last line in the Console and the current line
In IPython the ...: prompt in a code block isn't indented 2 spaces and therefore not aligned to the In [?]: prompt.
When an error occurs I get something like this:
Traceback (most recent call last):
File "C:\Program Files (x86)\PyCharm\helpers\pydev\pydev_run_in_console.py", line 69, in <module>
globals = run_file(file, None, None)
File "C:\Program Files (x86)\PyCharm\helpers\pydev\pydev_run_in_console.py", line 29, in run_file
pydev_imports.execfile(file, globals, locals) # execute the script
File "C:\Program Files (x86)\PyCharm\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "C:/Users/ca/Python/Bundeswettbewerb Informatik/Aufgabe2/Ameisen.py", line 133, in <module>
function_that_caused_error()
I don't need/want to see the traceback from the internals.
When running a file IPython needs to be started which takes some seconds even if I'm not going use the interpreted afterwards. I would like PyCharm to start IPython after the program has ended or when I start debugging (you can start IPython in an interactive console by doing import IPython; IPython.start_ipython()
There are some other minor things that I don't like:
When IPython is started it prints a lot of text to the console. I don't want to see any of it except maybe the version number (you can usually do this with the --no-banner option, but adding it to the interpreter options doesn't work)
when you type something and press Up it replaces what I have written with the last item of my history instead of replacing it with the last item of my history that start with what I have typed. Plain IPython does this.
I would like to have automatic code completion without having to press Ctrl + Space in the console
The "problems" are ordered by importance. Does anybody know how to change some of them? I could stop using IPython which would solve the second , the third and the fourth problem, but the other ones would still persist. All of this behavior (excluding the IPython stuff) is implemented very well in PyScripter.
EDIT:
I have found solutions to the first two problems and the problem with the IPython banner. The source for the PyDev interactive interpreter (which is used by PyCharm) is located, on Windows, in C:\Program Files (x86)\PyCharm\helpers\PyDev (path my vary of course).
So the first problem can be solved by editing the file _pydev_imps/_pydev_execfile.py. Wrap line 18 (exec(compile(contents+"\n", file, 'exec'), glob, loc)) in a try ... except block with the following code as the exception handler import traceback; traceback.print_exc(). This will terminate your Python program if there is an error while letting you interact with the variable afterwards.
Problem 2 can be solved by editing the fire pydev_run_in_console.py. Add this import at the beginning of the file: from pydev_console_utils import StdIn and insert sys.stdin = StdIn(interpreter, host, client_port) after what was line 61 before adding the import.
In order to solve the problem with the banner you have to download the most recent version of the PyDev source here and replace the files pydev_ipython_console and pydev_ipython_console_011 by their newer versions. In the newer version of the first file the __init__ method in line 22 has a argument called show_banner with the default value True. Change this to False.
This is probably not the answer you are searching for, but based on my experience using IPython on InteliJ products ( PyCharm, Ultimate), I don't recommend using their version of IPython. It's full of bugs, outdated and you'll lose precious time fixing problems instead of coding.
Have you tried jupyter notebook? If you installed python with anaconda, it's already installed. To run it, open the terminal and type:
jupyter notebook
If your browser doesn't open automagically, head to http://localhost:8888
Note:
You can automate this process by creating bat or sh script containing the code above inside your project directory, this way it doesn't start on you home dir, which it does by default.
Resources:
How to Install and Use IPython
nbopen project: Open a Jupyter notebook in the best available server
In all honesty, have you simply tried running a newer version of PyCharm and importing your settings? 3.5 is fairly outdated (I'm on 4.5.3 myself, newest version is 5.0) and I believe more support is offered for IPython in the newer versions. https://www.jetbrains.com/pycharm/help/ipython.html. Especially if you are a student, it might not hurt to give it a shot. I know older versions of PyCharm were more buggy than recent releases.
I realized that after compile a python script, It fixes the path information of this script.
For example:
I have a python script as /tmp/src/foo.py which has a single print command
print foo
Now I am compiling this code and move it to compiled directory.
python -m compileall -f /tmp/src/foo.py
mv /tmp/src/foo.pyc /tmp/compiled/
Then I am running the script and It gives error as I excepts
python /tmp/compiled/foo.pyc
Traceback (most recent call last):
File "/tmp/src/foo.py", line 1, in <module> # focus heree
print foo
NameError: name 'foo' is not defined
As you realize, file name of script appeared in error as its name before compilation. (Exactly same as path which I give to compile command)
Actually I have no problem with this situation, I am asking because I am just wondering. What is the reason and is there any way to see real path in errors?
In my opinion, we could not change binary file but maybe we can give a command line parameter to python when run compiled code or maybe we can add a code segment to source code ?
Thanks
Your question derives from the notion that a compiled version of a Python module can and should be moved under certain conditions. I've actually never heard of such a thing before, so until shown a specification which approves of such a thing, I'd say that this is an abuse and you are lucky to be able to run the .pyc file at all without the .py at its side.
If you think of the .pyc files as mere caches of the compiled versions of the original, then you can easily explain all phenomena you observed: The path of the original .py file is stored in the .pyc along with everything else coming from that source. If moved, that contents of course stays the same and will be used in error messages.
There is no way to see the "real" path in the error message because the place of the .pyc file isn't known anymore after loading it; only its contents is taken into account, and not its location, because combining those two things is a step of compilation. The interpreter won't compile again anything to an already compiled module. It takes it as it is.
Patching the .pyc file to show a different path also does not seem to make sense because that message is for helping you debug the problem. You probably won't debug anything in the .pyc file but only in the .py file. So it seems appropriate to rather have the path of that file in the error message.
I am using portable python 1.1 with python 2.6.2. The PyScriptor is 1.9.9.6. I open all the files I am working on with PyScriptor. So, I run my main file and an error shows up with code in one of my imported files. I fix it and run the main file again, but the same error shows up. It is as if the imported file is still the old one but PyScriptor is correctly saving the files I edit. Restarting PyScriptor fixes it, but is a pain to do that for every bug. I tested this happens bu adding a print statement that showed up after restarting, and then removing it and still see the print statement.
You can use reload(imported_module_name) in the interactive shell to reload the module before re-running your script. PyScripter does everything in a single Python instance, which makes debugging easier, but also, as you discovered, makes fixing imported files a bit trickier.
You can also completely reinitialize the Remote Engine from the Run menu to get a fresh interpreter.