I am using os.system("python game2.py") to run different parts of my code.
Every time I try this it gives me an import error for example "no module named pygame" even though when I game2 itself, it works fine.
What can I do?
Like said in other answers there is no need to run os.system() if you want to import the code. You can instead use the import function in python.
However I think the reason for the error with the command may be to do with what happens to the directories you are in when you run that command.
When you run the command the directory you are in is the same directory as the code is being run from. Then when you run the game2.py code and it tries to import pygame the reason it can't find it is because it is only looking the cwd (current working directory) as it normally would however the cwd could be different in the os.system() command.
Well, first of all, you shouldn't even do that for code in different files, you can just do import game2 and then run the functions inside of it. As an example, game2.RunGame(), If you have a function called that, of course this is just an example
Related
I have two .py files I wrote that I've imported into a third .py file to use:
(The top of driver.py)
import wafer_diagram
import LightIV
wafer_diagram.py and LightIV.py contain functions that I'm using in driver.py. However, whenever I have a cleared/restarted kernel, I have to run each individual .py file, otherwise they aren't defined in driver.py. Is there a way to automatically do this when I run driver.py? I am using Spyder with python 3.8. Thanks!
Edit: To clarify, after running wafer diagram.py and LightIV.py, I am able to use the functions in driver.py without issue. However, if I restart my kernel, and then try running driver.py, an error will throw that the two modules do not exist.
I was being very silly! Although I imported my other files, I was not calling on their functions correctly. For example, for the function print_struct() from LightIV.py, I would write in driver.py:
import LightIV
print_struct()
Instead, I should have written:
import LightIV
LightIV.print_struct()
The reason that I was able to get away with this for so long was likely due to how Spyder saves variables. I would run LightIV.py and wafer_diagram.py, "saving" their functions, and then using them later on instead of properly importing them.
I am new to coding and Python and have read a lot of similar questions about absolute/relative imports of modules but I cannot understand why my cronjob isn't working.
When I run from the terminal: python3 example.py the program runs without issue.
However when I schedule a cronjob to run "example.py", the program fails to run due to an ImportError. The first time it failed was due to a ModuleNotFound error, so I reinstalled the module in question (pyautogui) which seemed to solve that error.
I have tried using from . import pyautogui, os, time, smtplib, traceback instead of just import xyz but that brings up "ImportError: attempted relative import with no known parent package".
Can anyone help explain in simple terms what's going on here? Or point me in the direction of reading I can do to understand how terminal/cronjob is attempting to execute my program?
Thanks
Can anyone help explain in simple terms what's going on here? Or point me in the direction of reading I can do to understand how terminal/cronjob is attempting to execute my program?
Okay. Crontab programs are run under a different environment than the one in the terminal.
The surest way to check this is to run this bash script from crontab:
#!/bin/bash
set > /tmp/set.txt
It will dump the whole environment (probably you only need $PATH though) to "/tmp/set.txt".
Run the same script from terminal, saving to a different file. If you compare the two, you'll notice differences, for example again in the PATH.
And, you've guessed it, python uses PATH to find its various bits and pieces (and for that matter, which python is run if several are present also depends on PATH).
In the crontab file, you should notice, near the top, an assignment to both the SHELL variable and the PATH variable. Those are the values used by all following commands.
You should probably be able to set the PATH value to the same value you get from terminal, but keep in mind that you might disrupt the operation of any other script in the same crontab (that is why you should rather make use of /etc/cron.d files).
I wrote a simple python3.7 code like this :
import os
if __name__ == "__main__":
c = os.getcwd()
print(c)
This code path is ~/PyStudy/OsTest/test.py
When I ran it in VS Code and Terminal, different results appeared.
in Terminal, it returned: ~/PyStudy/OsTest
in VS Code, it returned: ~/PyStudy without /OsTest.
I used Code Runner in VS Code to run python code.
I don't know why, please help me.
Because they are running in different directories.
Apparently you started VS Code in the parent directory, and it simply keeps on running there until you terminate it.
Also apparently, you ran the script from the terminal by first doing a cd into this directory. There's no need to do that, though. Try
( cd /; python3 ~/PyStudy/OsTest/test.py )
at the Terminal prompt.
Generally speaking, the current working directory of a process is a convenience mechanism. By using relative paths, you can write shorter file names; but in most situations, you can use an absolute file name instead, from a process running in any directory.
If it's returning different values, you can be sure it's returning the correct values. The difference must be in the way you're running the program. Vs code probably sets its working directory to something different than what you were doing when running from a terminal.
The entry points for execution are different for both. That is why it is happening.
I have a script called startup_launching.py, which does something like this:
import os
# launch chrome
os.startfile(r'C:\Program Files (x86)\google\chrome\application\chrome.exe')
To run this from the (windows) command line, I enter:
python "FILEPATH\startup_launching.py"
That works fine.
However, I have a separate script called threading.py, which does this:
import time, threading
def foo():
print(time.ctime())
threading.Timer(10, foo).start()
foo()
(which I found on stackoverflow).
When threading.py is saved in the same folder as startup_launching.py, it seems to interfere with startup_launching.py when I run it from the command line (e.g. one of the error messages is: module 'threading' has no attribute 'Timer').
When I move threading.py to another folder, startup_launching.py works fine again.
Can someone explain what's going on here? I assumed that entering:
python "FILEPATH\startup_launching.py"
in the command line would only look in startup_launching.py
Thanks!
you should rename your file so that it is not named threading.py, since it will be in the import path and will mask the actual built-in threading module, which the other script relies upon.
Name your module something other than threading.py because there is a built-in module named threading.py.
Don't call it threading.py. Also, check your python version, if it correspond to the tutorial that you were reading.
When I import the wx module in a python interpreter it works as expect. However, when I run a script (ie. test.py) with wx in the imports list, I need to write "python test.py" in order to run the script. If I try to execute "test.py" I get an import error saying there is no module named "wx". Why do I need to include the word python in my command?
PS the most helpful answer I found was "The Python used for the REPL is not the same as the Python the script is being run in. Print sys.executable to verify." but I don't understand what that means.
Write a two line script (named showexe.py for example):
import sys
print sys.executable
Run it both ways as showexe.py and python showexe.py. It will tell you if you're using the same executable in both cases. If not, then it'll depend on your operating system what you have to do to make the two run the same thing.
If you start your script with something like #!/usr/local/bin/python (but using the path to your python interpreter) you can run it without including python in your command, like a bash script.