I currently have python 2.x and 3.x installed on my windows machine, id like to have both for comparison and also 2.x for pygame.
now i know if i want to run a python script in the command prompt i would use the following:
python filename.py
i know java also uses the "java" prefix before it if you want to run a java file.
Now in doing this, it automatically sets up python 3.x environment, which i dont mind, but i was wondering is it possible to set up 2.x enviroment by setting a variable called "Python2" and another for python 3.x such as "Python3" so that i could set up the environment without having to use the trick of adding the environment each time in the .py script?
this might be a silly question, but im not overly familar with command prompt's enviroment variables and its keywords, i did try googling it but alot of people just ended up suggesting either env path in the file or manually change the enviromental path each time.
Update
My machine is running windows 8.1
Follow this tutorial (upto step#4):
http://www.computerhope.com/issues/ch000549.htm
Then click on NEW -> add the 2 paths with their call names
Python2,
Python3,
While doing this, you may want to add all these to PythonX path :
C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk;
C:\other-foolder-on-the-path (other folders)
After snooping about SO, i eventually found my answer, i guess it never came up in my initial searches for some reason
How to switch between python 2.7 to python 3 from command line?
Related
I have windows 10 with 2 user accounts, one is an old one that has Python installed. My latest account also has Python installed. I used pip install tweepy, and it now exists in the site packages. If I open my Python shell (v3.6.5), it imports fine. However, I can't get this to work when switching to Python in cmd. In here, after typing python, it says Python 3.6.6. Obviously they are different, yet they seem to be originating from the same directory.
Any ideas?
[edit] I have just realised that I have an external application that runs on Python 3.6.6., so I guess it's defaulting because of that. However, I can't uninstall that since I need it - is there a way to specify which version of Python is launched when I type python into the cmd?
[edit2]: This is the issue, and the solution there works. However, I want to be able to just type python into cmd, rather than the entire path. Since both exist in the path (and I don't want to remove the other 3.6.6.), is there a way to achieve this?
Have you thought about using a virtual environment?
https://virtualenv.pypa.io/en/latest/
When you enter "python" into your cmd it searched python.exe in the directories listed on your PATH variable.
All you need to do is to modify your PATH and add the directory path in which the python with the desired version is located.
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.
Created virtual environment in ~/python/venv/venv_python2 folder.
I can run python in a regular way (for venvs):
source ~/python/venv/venv_python2/bin/activate
python
or I can run python with:
~/python/venv/venv_python2/bin/python
What is a difference between 2 above?
There is no difference.
You can check where python is running from by typing which python in bash. You'll see that it points to your virtual env when you're in it.
The purpose of the virtual environment is to isolate the dependencies inside it so you don't have to worry about knowing the precise path to the correct Python interpreter or the libraries you have installed. So while using the absolute path is technically not incorrect, it completely bypasses the facilities of the virtualenv, and could eventually end up pointing to the wrong location if you hardcode it in a script today, and decide to move, migrate, or refactor your virtualenv tomorrow.
There is a very slight, almost irrelevant difference between the two:
~/python/venv/venv_python2/bin/python specifies exactly which Python interpreter you want to use.
python runs which ever interpreter is found first when examining your path.
One of the things that source ~/python/venv/venv_python2/bin/activate does is that it puts ~/python/venv/venv_python2/bin at the front of your path, so that when you run /-free command, the first place the shell looks is that directory, meaning python will resolve to the one in your virtual environment.
So, the only way your two ways would differ is if something else modified your PATH in the meantime.
So, I've been toying around with python environments and I think i screwed mine up.
So when I ran python in shell, it would tell me i'm running on 2.7
I'm on windows 10, and i need a python switcher for my next project so i download pywin and used pywin to switch it to 3.5
the command i used was
pywin setdefault 3.5
now when i type python it says
python is not recognized as an internal or external command.
but py produces
Python 2.7.12
Now i can't use pip, easy_install, virtualenv
all of these commands i used to use, i suddenly no longer have access to them.
I tried switching back
but it wont even recognize pywin anymore.
The best way to check which Python version is executed is to check your environment variables. Another way of checking this is using the which command. (open cmd and run which python).
But, first you need to start a new cmd prompt to ensure your environment variables are not altered.
On Windows, but also any OS, you need to check the PATH and PYTHONPATH variables.
For Windows, follow the recommandations available in the Python documentation.
If you're not very experienced with working with windows, installations, and other similar things, I would recommend that you uninstall python, delete all versions/folders containing python (compiled) files (those that were installed with python, not the ones you've written) and then reinstall python. The installer should re-set the path variable to the correct location.
I am trying to run script in bash from python, but I am currently working in a virtualenv, and when my script calls on a specific program, I get "usr/bin/env: luajit: No such file or directory".
When I run the same script inside a separate bash window (outside the virtualenv), it runs perfectly.
I have a feeling it is because this program is not properly being pointed to, but have no idea how to tell my virtualenv to look for that program.. How do I get around this?
I am on Ubuntu 14.04, using python 2
The answer lies in environment variables. PATH should contain the location where your luajit is.
See setting an environment variable in virtualenv for some ways to automatically set environment variables in a virtualenv (but two of the currently suggested ways require wrappers and one - editing a stock script). There's no magic: virtualenv edition by Allison Kaptur describes the (rather simple) magic behind virtualenv's work so you may be able to find an even better place to put the variable assignment in.