I'm having the same problem on Windows and Linux. I launch any of various python 2.6 shells and run nose.py() to run my test suite. It works fine. However, the second time I run it, and every time thereafter I get exactly the same output, no matter how I change code or test files. My guess is that it's holding onto file references somehow, but even deleting the *.pyc files, I can never get the output of nose.run() to change until I restart the shell, or open another one, whereupon the problem starts again on the second run. I've tried both del nose and reload(nose) to no avail.
Solved* it with some outside help. I wouldn't consider this the proper solution, but by searching through sys.modules for all of my test_modules (which point to *.pyc files) and deling them, nose finally recognizes changes again. I'll have to delete them before each nose.run() call. These must be in-memory versions of the pyc files, as simply deleting them out in the shell wasn't doing it. Good enough for now.
Edit:
*Apparently I didn't entirely solve it. It does seem to work for a bit, and then all of a sudden it won't anymore, and I have to restart my shell. Now I'm even more confused.
Related
I have a short script written in python that saves a simple .txt to the same directory the .py file is in. Problem is: It only does so on one of my two computers.
My code doesn't include a hard-coded path to write to. On my laptop, I can put the makemeanote.py in any folder and it will create the note right there. On my desktop pc, all the notes end up in System32. PATH is set exactly the same way on both machines, and both use Windows\py.exe as the executable.
Somewhat interestingly, I only get an admin-screen on the desktop pc, asking if I want to allow changes to my system by "Built: Release_master_v3.8.2_"etc., whereas on my laptop it simply runs and does its job.
No amount of un- and reinstalling has changed anything, even when I thought I had eradicated any trace of python on my hard drive. Both PCs use current Win10/64 installations.
What is happening there?
A clarification: It's not about fixing the bug, it's about understanding the inconsistent behaviour! I know I could just hard-code any directory, but that takes away the beauty, don't you think?
I finally found the cause of the weird behavior:
For some reason, the py.exe in my WINDOWS folder was set to always be run as admin. As soon as I unchecked that option, the User Account Control (UAC) check disappeared and my file finally behaved as I had expected.
During a presentation yesterday I had a colleague run one of my scripts on a fresh installation of Python 3.8.1. It was able to create and write to a csv file in his folder (proof that the csv library was working correctly), but everything else failed due to not being able to find the needed files. To try and isolate the problem and figure out why, we tried the below simple script, which also failed.
He had this test.py script in "D:/TEST", which also contained some folders and image files. Running this script printed nothing to the console. No empty list, no error message, no newline. Maybe the print() function was also not working, but I didn't get around to testing that.
import os
print(os.listdir())
This script works fine on my computer and my other colleagues computers (all Windows 10, similar hardware). I didn't have time to look into the issue more thoroughly and don't have access to his computer anymore. What could be the problem? What other things could I have him look into in order to fix this? In case this problem appears again during a future presentation, what steps could I take to figure out the cause of it?
My colleague uninstalled Python and reinstalled it. After doing this apparently the "python" command will no longer run his scripts, but using "py" instead will. Now that he is using "py" to run his scripts, it is working as expected.
I am trying to find ways to make better use of my time while programming.
I have a python script that does some heavy work (it can take hours) to finish. Now, most of the work it does is network related, so i have plenty of cpu resources to spare.
If the script was a C binary executable, it would be fine to git checkout onto a different branch and do extra work, I could even modify the binary in disk as it has been copied to ram, so until it finishes running I won't affect program output.
But python scripts are translated, not compiled. What happens if I start tampering with the source file, can i corrupt the programs output, or is the text file and associated imports copied to RAM, allowing me to tamper with the source with no risk of changing the behaviour of the running program?
In general, if you have a single Python file which you run as a script, you're fine. When you run the file, it is compiled into bytecode which is then executed. You can change the original script at this point and nothing breaks.
However, we can deliberately break it by writing some horrible but legal code like this:
horrible.py:
from time import sleep
sleep(10)
import silly
silly.thing()
silly.py:
def thing():
print("Wow!")
You can run horrible.py and while it is running you can edit silly.py on disk to make it do something else. When silly.py is finally imported, the updated version will be loaded.
A workaround is to put all your imports at the top of the file, which you probably do anyway.
When a python program is run it is compiled (kinda, more like translated) into a .pyc file that is then run by the python interpreter. When you change a file it should NOT affect the code if it is already running.
Here is a related stackoverflow answer. What will happen if I modify a Python script while it's running?
Why not have another working directory where you make your modifications? Is there a lot of ancillary data or something that makes it hard to set up a working directory? I.e. if your working directory is A, git clone A B, and then work in B. When you're done, you can pull the changes back from B to A:
git remote add B ../B
git pull B master
I have a single unit test file, and I can run tests within Pycharm. Fine. However, it seems that Pycharm skips tests based on some criteria regarding code change. Something like, if the code in a test method hasn't changed, and/or if the code that a particular test method is testing hasn't changed, it won't run the test. This has caused a lot of pain, and has let a bug fall through that wasn't caught until much later on. So my question is, how to stop Pycharm from automatically skipping tests and force it to run all tests?
Why is skipping tests the default behaviour anyway? This seems absolutely outrageous to me, but please correct me if I'm wrong.
EDIT
Oops my bad. I ran the tests by pressing the keyboard shortcut control-shift-R on my Mac OS, which normally runs a Python script, but it doesn't actually run the whole test file, and only runs a single test (where the caret is) instead. This (keyboard shortcut having different behaviours) is a little bit misleading in my opinion, but regardless, my description of the problem is wrong and I was wrong. Sorry!
Make sure all your test methods staring with a test_.
Usually I have 2 Tests configurations: All and Current.
tests folder is located in the root of PyCharm project
I use python path to specify certain test to run.
You can easily copy the reference to certain test
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.