I wrote a program that use pyperclip module and it would work from Pycharm and python IDLE, would work as well if starting from Powershell but if I try to start the program from WIN+R, when launched, the program returns an error saying that pyperclip module is not installed. The same problem appears when I run it from the Anaconda Powershell Prompt.
PLEASE NOTICE:
The program was working perfectly before I installed Anaconda and Jupyterlab.
The error occurs when I run the program from the cmd using WIN+R AND when I run it from the Anaconda Command Prompt but it's fine when run from IDLE, Powershell, Pycharm.
I always used python 3 and only yesterday I installed Anaconda.
Thanks for the help!
I just spent couple of hours trying to solve exactly the same problem. What I found out is that, as couple of members have already pointed out, the main problem is the mismatch between the version of the python that runs in cmd and the versions of the python used in scripts/batch files.
The first line in the code, known as "shebang", in .py file indicates the version of the python that the script should use when it is executed. So, it must match the version run by default with cmd (or when executed with win+R). In my case, I also have a batch file (.bat) that calls specified version of the python, which should be the same version used with .py file.
The problem was that both of my files (.py and .bat) were calling python 3.8 while the cmd is running version 3.7. Initially, I used shebang #! python3 in my .py file, and command #py path/to/python/file.py %* (and I also tried #py.exe path/to/python/file.py %*) in my .bat file, and that did not work.
To solve the problem, I updated these two files to link to python version 3.7 with following:
changed shebang in .py file to #! python
changed command in .bat file to #python path/to/python/file.py %*
With these changes the system runs the program with win+R.
whew, taking course on python and instructor had py.exe instead of python.exe in .bat call. despite trying all of the other installation methods others have mentioned, just changing this to python.exe did that trick.
Related
I've been messing around with AutoHotKey, trying to create some useful shortcuts for myself. I can open file explorer, calculator, chrome, etc., but I haven't been able to write a program that opens Python IDLE.
My program says:
!t::
Run pythonw
return
I've tried pythonw.exe, python.exe, python, python3.exe, and a bunch of other combinations. Any idea why it isn't working? Thanks!
So, your problem is that Python IDLE is different from pythonw.exe, python.exe, python, python3.exe .
Python IDLE is an IDE or Code Editor provided with python whereas pythonw.exe, python.exe, python, python3.exe are the python interpreter.
pythonw.exe - for executing python scripts without opening console window(Hidden)
python OR python3.exe OR python3.exe - are the same, that is the normal python interpreter.
So to open IDLE you should execute the IDLE file not the interpreter.
The path for IDLE(in Windows Computer) is usually :
C:\Python39\Lib\idlelib\idle.bat
Here the Python version is 3.9 but it may be different in your case!
Check for the version you installed by opening command prompt and typing :
C:\>python --version
Python 3.9.1
Turning the info that Jaysmito provided into an AutoHotkey Script:
!t::
Run C:\Python39\Lib\idlelib\idle.bat
return
However, the Python39 part of the directory above will vary based on which version of python you have installed. To check which version of Python you are using, use the python --version command in a command prompt window. Then if your version of Python is not in the 3.9.* range, change the directory above to match your version.
For example, if your version is in the 2.7.* range, your directory would be something like Run C:\Python27\Lib\idlelib\idle.bat, with the Python39 from above changed to Python27.
idle.bat is Windows specific, and there are Windows-specific reasons for its existence. The generic way to start IDLE in its default startup mode (partly user customizable) is somepython -m idlelib where somepython refers to and start a python binary. It can be python, pythonw (Windows), python3 (*nix), or py -3.y (Windows). For 2.x, use idlelib.idle instead of idlelib.
I've been studying Python for a month now and normally I run all my programs in Sublime Text 3.
Today I learn to run Python programs in the terminal window as introduced in this section of the Automate the Boring Stuff with Python book following this video. Basically, I followed the instruction in the video and created the hello.py file as below:
#! python3
print('Hello, World!')
Then I opened the Command Prompt to run the file with the command: py.exe c:\users\danh\mypythonscripts\hello.py,
an error pops-up and states that "This app can't run on your PC" and a line says that Access is denied. I spent the whole day trying to fix this problem but still I couldn't get it running.
One thing is when I change the directory of the Command Prompt to run the file to C:Windows\system32 (or run the Command Prompt as Administrator) and then run the command py.exe c:\users\danh\mypythonscripts\hello.py, it runs the file without any problem as in this image.
Does anyone know how to fix this problem? Any help is appreciated. Thanks!
I solved the problem.
When I looked into my user directory at C:\Users\<Username>, it appears that there is a py.exe file that has 0 bytes.
I was told in this thread that the py.exe file shouldn't be in my user directory so I removed that file and it fixed the problem.
I still don't know how the py.exe file got into my user directory and why it has 0 bytes so I'm not sure this solution could help others. For now, I will accept my own answer because it solves the problem in my case.
It looks like you're trying to use Microsoft's new Windows 10 Metro-based auto-installing version of Python. It's included by default but, as you've found, it doesn't work very well.
Try installing the version from the Python website.
If you've got a 32-bit copy of Windows, make sure to install the 32-bit version; Windows isn't very good at running 64-bit programs from a 32-bit kernel. You can check by looking in your C: drive; if you haven't got a Program Files (x86) folder, install the 32-bit version.
python.exe inside my env\Scripts\ became 0kb for some reason. So I created another virtual-env and copied python.exe from there to this folder. then it started working.
I think I am close to solving my issues but need a little help.
Computer: Mac
My situation: wrote a script in Jupyter Notebooks (.ipynb) and I wanted to run it from IDLE. So I downloaded the .ipynb as a .py file. When I open up the file it opens in Idle and when I go to run the file it says I do not have the module/packages installed.
At the top of the .py file it put #!/usr/bin/env python
When I run which python in my terminal I get /opt/anaconda3/bin/python.
So I am thinking IDLE is running the script through a different environment of python. How do I change it so IDLE will run the script through the python Anaconda also uses?
Thank you!
It is possible that you have more than one python in your OS. Just check the versions in prompt with --version. If you get different python version you need to delete one that you dont use. It is generally the other than anaconda one.
I'm trying to run a Python script from the command line as a command on Windows -- so no usage of "Python" or ".py". If my script is named "testing.py", I am attempting to make this name into a command and call "testing" from the command line.
Going through the docs it seems I need to use this shebang #!/usr/bin/env python as long as I have Python in my PATH.
https://docs.python.org/3/using/windows.html#shebang-lines
I also have the script folder in my PATH, so something like
"testing.py" is currently working from the command line.
According to the docs and this tutorial,
https://dbader.org/blog/how-to-make-command-line-commands-with-python
I should be able to evoke my Python script just by "testing" if I have the proper paths within PATH and the above shebang. However, I can't seem to get the script running withouth adding ".py".
The accepted answer by #AKX is incorrect for Windows 10 standard Python 3, certainly in the latest Windows 10 (1903) if not earlier.
(Note: I cannot speak to how this may or may not work under WSL.)
I have several versions of Python installed (2.7, 3.6, 3.7, and most recently Python 3.8b1). I've been using the #!/usr/bin/env shebang for years in my scripts for cross-platform compatibility (usually to distinguish Py2 vs Py3 scripts).
I've created a little script in a folder (C:\so_test\awtest.py):
#!/usr/bin/env python3.6
import sys
print(sys.version)
If I run this with awtest.py or just awtest I get 3.6.x reported (showing it's running with Python 3.6). If I change the shebang to refer to 3.7, I get 3.7.x reported. If I change the shebang to just #!/usr/bin/env python3 I get the latest version of Python installed (3.8).
Now, if I add that folder to my path (path=%PATH%;C:\so_test in the command window you're testing in, or in the main env vars (you will need to restart the command window if you do the latter though)), I can change to a different directory and run awtest or awtest.py and they still work and refer to the folder in the path. If I remove the script folder from the path these files are no longer found.
While I wouldn't necessarily expect this to work on Windows prior to 10 or Python 2.7, this functionality appears to be the way of things going forward.
No, Windows does not support shebang lines.
The documentation you've linked relates to the py launcher installed by Python, which can interpret various shebang lines to choose a Python version to run a script with.
setuptools is able to generate wrapper .exes for your Python scripts, but it gets a little involved and already assumes you have a package with a setup.py and so on.
Locally, if you really, really need this, you probably could add .py to the PATHEXT environment variable, so the Windows command line looks up .pys like it looks up .exes (and various others; the current modern default is .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC). However, this will naturally not scale for distributing apps, as all of your users would need to set that too.
My recommendation is to stick with just that boring old python testing.py, really.
You can use shebang in windows by setting the path of your interpreter as the first line in the file(you will see a marker on VSCode that says 'set as interpreter ' on that line).
Using windows 10,Python version 3.9 see example:
#!C:/Users/waithira/AppData/Local/Programs/Python/Python39/python.exe
print('hello world')
if you're not going to do this often. You can still add a batch file to your path testing.bat containing the command that you need to execute your code.
#echo off
python testing.py
It's a borring workaround but it works without needing to mention the extention since windows interpret batch files the same way it interpret executables.
I seem to have problem launching python from command line. I tried various things with no success.
Problem: When trying to run python from the command line, there is no response i.e. I do not get message about 'command not found' and console does not launch. Only option to open python console is to run C:\Python34\python.exe directly. Running using python command does not work even when in the python directory but python.exe launches. Issue with the launching this way is that python console is launched in new window. This whole problem is present only on one machine while on my other machine I am able to run python correctly and console launches in the command prompt window from which the python command was executed.
PATH is correctly set to
C:\Python34\;C:\Python34\Scripts;...
and where python correctly returns C:\Python34\python.exe. I verified that running other commands imported through PATH (such as javac) run correctly.
Things I tried:
Completely re-installing python both with x86 and x64 python installations with no success.
Copy installation from my second machine and manually set the path variables - again no success.
Can anyone hint how to resolve this behavior?
(Additional info: Win 8.1 x64, python 3.4.2)
Issue resolved. Since no feasible solution was found in 2 days, I decided to wipe all keys containing 'python' from registry as well as some files that were not parts of other programs. This resolved the issue after re-installing python.
If anyone finds the true cause of this misbehavior and other - less brutal - solution, please write it here for future reference.
Recent Python installer has option to add PATH.
If you didn't use it, you can register directory where python.exe is to PATH environment variable.
But I prefer py launcher. It may be installed via Python 3.3 or 3.4.
With it, you can start Python via py or py -3.4.
See https://docs.python.org/3/using/windows.html#python-launcher-for-windows