Problems with different versions of python - python

Questions similar to this one have been asked but I haven't seen a solution yet that helps me.
I am running Windows 7 and I've installed two versions of python, 3.3 and 2.7. Python 3.3 was the first version I installed and I was able to run scripts from the desktop (not the command line). I installed python 2.7 so that I could get numpy, scipy, and matplotlib down the road, but I found that all the scripts on my desktop defaulted to python 2.7. Since I coded in 3.3 this caused some issues.
I was able to fix this by right clicking the script icon, browsing programs, navigating to the python 3.3 file in my C: drive, and selecting the idle inside that directory. But then I found I wasn't able to run those scripts with python 2.7 using the exact same procedure.
Unfortunately I don't know command-line programming very much at all, and it seemed like most of the answers were geared towards that as a solution. Ideally I'd like to specify which python I want to run a script from the desktop, or possibly while I'm editing the script.
If it's relevant I'm running the eric python IDE, version 5.
I'd be happy to do the work of reading something fairly technical and long (like a blog post or PDF), but it won't help me much if it isn't aimed at beginners.

The Windows Python Launcher can automatically detect the Python from the shebang in your file.
Start your Python 3.3 scripts with
#!/usr/bin/env python3
and your Python 2.7 scripts with
#!/usr/bin/env python2.7
If you want to use the system's default Python version, you can just start the file with
#!/usr/bin/env python
This will also work on virtually all Unix systems.

Maybe you should chose another IDE, like PyCharm, it could manage different versions of python easily (and gives tons of other useful features). Perhaps free PyDev could also make it.
Also, using virtualenv — is the best solution here, but it's a "hard way".

The method I use is to have several cmd.exe shortcuts on my desktop, each pointing at a different runpython.bat file, one for each version of python. Here is one command example from a shortcut:
%comspec% /k "C:\QA\Python\QAPYTH3\runpython.bat"
Here is a typical runpython.bat:
#SET PATH=%PATH%;"C:\Python32"
#SET PYTHONPATH=C:\Python32\Lib
#ASSOC .py=Python.File
#ASSOC .pyc=Python.CompiledFile
#ASSOC .pyo=Python.CompiledFile
#ASSOC .pyw=Python.NoConFile
#FTYPE Python.CompiledFile="C:\Python32\python.exe" "%%1" %%*
#FTYPE Python.File="C:\Python32\python.exe" "%%1" %%*
#FTYPE Python.NoConFile="C:\Python32\pythonw.exe" "%%1" %%*
#SET PATHEXT=.py;%PATHEXT%
Of course you don't have to call your .bat files the same as I have. Just adjust to suite your setup.

Related

How do i know if a script is to be run with Python 2 or Python 3 [duplicate]

How do I, in the main.py module (presumably), tell Python which interpreter to use? What I mean is: if I want a particular script to use version 3 of Python to interpret the entire program, how do I do that?
Bonus: How would this affect a virtualenv? Am I right in thinking that if I create a virtualenv for my program and then tell it to use a different version of Python, then I may encounter some conflicts?
You can add a shebang line the to the top of the script:
#!/usr/bin/env python2.7
But that will only work when executing as ./my_program.py.
If you execute as python my_program.py, then the whatever Python version that which python returns will be used.
In re: to virtualenv use: virtualenv -p /usr/bin/python3.2 or whatever to set it up to use that Python executable.
Perhaps not exactly what you asked, but I find this to be useful to put at the start of my programs:
import sys
if sys.version_info[0] < 3:
raise Exception("Python 3 or a more recent version is required.")
I would use the shebang #!/usr/bin/python (first line of code) with the serial number of Python at the end
Then run the Python file as a script, e.g., ./main.py from the command line, rather than python main.py.
It is the same when you want to run Python from a Linux command line.
While the OP may be working on a nix platform this answer could help non-nix platforms. I have not experienced the shebang approach work in Microsoft Windows.
Rephrased: The shebang line answers your question of "within my script" but I believe only for Unix-like platforms. Even though it is the Unix shell, outside the script, that actually interprets the shebang line to determine which version of Python interpreter to call. I am not sure, but I believe that solution does not solve the problem for Microsoft Windows platform users.
In the Microsoft Windows world, the simplify the way to run a specific Python version, without environment variables setup specifically for each specific version of Python installed, is just by prefixing the python.exe with the path you want to run it from, such as C:\Python25\python.exe mymodule.py or D:\Python27\python.exe mymodule.py
However you would need to consider the PYTHONPATH and other PYTHON... environment variables that would point to the wrong version of Python libraries.
For example, you might run:
C:\Python2.5.2\python.exe mymodule
Yet, the environment variables may point to the wrong version as such:
PYTHONPATH = D:\Python27
PYTHONLIB = D:\Python27\lib
Loads of horrible fun!
So a non-virtualenv way, in Windows, would be to use a batch file that sets up the environment and calls a specific Python executable via prefixing the python.exe with the path it resides in. This way has additional details you'll have to manage though; such as using command line arguments for either of the "start" or "cmd.exe" command to "save and replace the "console" environment" if you want the console to stick around after the application exits.
Your question leads me to believe you have several Python modules, each expecting a certain version of Python. This might be solvable "within" the script by having a launching module which uses the subprocess module. Instead of calling mymodule.py you would call a module that calls your module; perhaps launch_mymodule.py
launch_mymodule.py
import sys
import subprocess
if sys.argv[2] == '272':
env272 = {
'PYTHONPATH': 'blabla',
'PYTHONLIB': 'blabla', }
launch272 = subprocess.Popen('D:\\Python272\\python.exe mymodule.py', env=env272)
if sys.argv[1] == '252'
env252 = {
'PYTHONPATH': 'blabla',
'PYTHONLIB': 'blabla', }
launch252 = subprocess.Popen('C:\\Python252\\python.exe mymodule.py', env=env252)
I have not tested this.
You can't do this within the Python program, because the shell decides which version to use if you a shebang line.
If you aren't using a shell with a shebang line and just type python myprogram.py it uses the default version unless you decide specifically which Python version when you type pythonXXX myprogram.py which version to use.
Once your Python program is running you have already decided which Python executable to use to get the program running.
virtualenv is for segregating python versions and environments, it specifically exists to eliminate conflicts.
For those using pyenv to control their virtual environments, I have found this to work in a script:
#!/home/<user>/.pyenv/versions/<virt_name>/bin/python
DO_STUFF
I had this problem and just decided to rename one of the programs from python.exe to python2.7.exe. Now I can specify on command prompt which program to run easily without introducing any scripts or changing environmental paths.
So i have two programs: python2.7 and python (the latter which is v.3.8 aka default).
While working with different versions of Python on Windows,
I am using this method to switch between versions.
I think it is better than messing with shebangs and virtualenvs
install python versions you desire
go to Environment Variables > PATH
(I assume that paths of python versions are already added to Env.Vars.>PATH)
suppress the paths of all python versions you dont want to use
(don't delete the paths, just add a suffix like "_sup")
call python from terminal
(so Windows will skip the wrong paths you changed,
and will find the python.exe at the path you did not suppressed,
and will use this version after on)
switch between versions by playing with suffixes

Python script packed with cx_Freeze: how do I force windows to use an alternative console?

I'm a very unexperienced programmer who has just began studying Python. I managed to do some basic stuff and now I tried packing my .py files to .exe files that can be shared with friends who don't have Python installed. I'm using python 3.4 so I was forced to use cx_Freeze which is pretty easy to understand, but I have a question: is there a way to "embed" a different console than cmd.exe in those .exe's?
I wrote some scripts that work only with command line, but window's console is pretty ugly and frustrating. I want my packed .exe to be opened with a more friendly console (even something like IDLE), is that possible? (everything must be packed in the final .exe, because this have to work even on an external pc that doesn't have python installed or a specific console installed).
Sorry for my bad english!
May be you should look to "py2exe" which is only build for windows.
I'm not sure at all you can embed "idle" in you "compiled" python project. If you need a more windows friendly presentation, I suggest you use wx python library which can be easily embed in your py2exe project.
see http://sourceforge.net/projects/py2exe/ and http://wiki.wxpython.org/py2exe

How to install python 3.2.3 on Windows 7 enterprise

although I have been using python a long time very easily in a Linux environment, I have tremendous trouble to even install it correctly in a windows environment. I hope this is a question to be asked here, as it is not directly a programming question.
Especially, I have the following problems:
When on the command line, python is not a recognized command. Do I have to set the Windows path manually myself? If so, how to do that?
When starting a python script, should this be done with python.exe or pythonw.exe? What is the difference?
I also tried to install ipython several times, it never got installed (even after following the starting ipythonenter link description here thread.
When starting a script with python.exe, a window pops up and closes immediately. I saw some hints in putting in a readline command, which is of no help if there is a syntax error in the script. So how to be able to keep the window open, or how to run the command on the cmd.exe?
Thank you for any help on these items.
Alex
1) Look here: www.computerhope.com/issues/ch000549.htm
2) It has already been answered, always try to use search before asking question:
pythonw.exe or python.exe?
4) When using cmd.exe just navigate to your script folder using dir for changing directories and C:,D:,etc. for changing drives. Then run script by typing just the script name. When installed correctly, Python automatically launches .py scripts with python, so you don't have to write 'python' before script name. When run in cmd, window will stay open. If you want it to stay open even when launching script with double-click, use function waiting for user input, see here How to keep a Python script output window open?
You might want to use Python3.3, there is a new launcher for Python scripts in it. By that, you can start Python scripts with py <scriptname> which has the benefit of being installed in your path (C:\Windows\system32) and you can use a shebang to tell whether the script is for Python2 or Python3.
Also
In addition to the launcher, the Windows installer now includes an
option to add the newly installed Python to the system PATH
(contributed by Brian Curtin in issue 3561).

Cross-platform way to specify Python interpreter when running with execv

I am currently running a Python scripts both on Linux and Windows 7. The file is executed in an execv style with which I mean that the interpreter is defined in the beginning of the file in a command.
In Windows system, the interpreter specification is:
#!C:\Python26\python.exe
However in Linux this needs to be
#!/usr/bin/python
I would like to run this script in both systems without having to change this line again and again.
I have tried out the following:
#!C:\Python26\python.exe
#!/usr/bin/python
as well as:
#!C:\Python26\python.exe;/usr/bin/python
So: is there any way I could specify multiple interpreters?
Depending on what you're trying to do, this might be a bit heavy-weight, but 0install can run your program will the appropriate Python interpreter for your platform. In your program's XML description, do something like this (e.g. if you want Python >= 2.6, < 3):
<command name="run" path="myprog.py">
<runner interface="http://repo.roscidus.com/python/python">
<version not-before="2.6" before="3"/>
</runner>
</command>
See: http://www.0install.net/local-feeds.html
This will also make 0install download a suitable version of Python if the user doesn't have it already.
Note that you may want to do this even if you're only targetting Linux, because with Python 3 there is no single #! line that works on all platforms (some platforms, e.g. Arch, require "python2" not "python", while others, e.g. Debian, don't provide "python2", only "python").
#!/usr/bin/env python
That will call the env program to search your PATH for a Python executable.
If you need to ensure a specific version of Python you can do e.g.:
#!/usr/bin/env python3.11
Is there any way I could specify multiple interpreters ?
You don't need to. On Windows (at least as long as you don't have CygWin or similar installed), the Shebang line is treated as a normal Python comment; that means, it is ignored. Windows knows that it should run .py and .pyw files with the Python interpreter, because it is told that upon installation of Python.

Using Python 3.1 with TextMate

TextMate seems to use the built-in Python version I assume (sys.path doesn't work). How do you configure it to use 3.1 instead? I've already installed the 3.1 package and I can use IDLE for interactive sessions, but I need to use TextMate now.
Thanks
TextMate uses the value of the TM_PYTHON variable to find the path to the Python interpreter. A good solution is to take advantage of TextMate's ability to define variables like TM_PYTHON on a per-project basis:
Open a new or existing TextMate Project (File -> New Project or File -> Open)
De-select any file in the project list sidebar.
Click on the Get Info (i) icon in the sidebar. A Project Information pane appears.
Click + to add a new variable.
Enter TM_PYTHON in the Variable field and the full path to the desired python in the Value field (for example, /usr/local/bin/python3.1).
Close the Information window and save the Project (File -> Save Project As).
Then you can add files as needed to the project and they will be run under the chosen python with TextMate Python bundle's Run Script command. You might want to save a Python 3 project, say, for running ad-hoc scripts under Python 3. For bigger projects, you'll want to create a separate TextMate project for it anyway.
To change the Python version used globally within TextMate:
From the TextMate menu bar, open TextMate -> Preferences
click on the Advanced pane
click on the Shell Variable tab
click the + to add a new variable
enter TM_PYTHON in the Variable field and the full path to the python in the Value field (perhaps /usr/local/bin/python3.1)
As Alex points out, you may break other TextMate functionality by changing the Python version globally so the per-project change is probably a better solution.
UPDATE (2010-10-31):
There is another approach that may be easier to use for some projects. The Run command in TextMate's Python bundle appears to respect a shebang line in the file being run. So, instead of modifying TM_PYTHON, you can specify the path to the interpreter to be used by including a first line like this:
#!/usr/local/bin/python3.1
# sample code to show version
import sys
print(sys.version_info)
In many case you would prefer not to hardwire the absolute path but manage use through the normal shell PATH environment variable. Traditionally /usr/bin/env is used for that purpose. However when running under TextMate, your shell profile files are not normally used so any changes to PATH do not show up there including possibly /usr/local/bin or /opt/local/bin or wherever your desired python3 command is located. To get around that, you can add or modify a global PATH shell variable to TextMate -> Preferences (see above) with a value of, say, /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin. Then you can use a more general shebang line like this:
#!/usr/bin/env python3
(This all seems to work with the most recent vanilla TextMate and its Python bundle: no guarantees about earlier versions or with other Python bundles.)
Late to the party, sorry! I take it you want to run the script using TextMate's 'built-in' interpreter? I've found the simplest solution is to add a shebang, which works extremely well;
#!/usr/bin/env python3
for python 3.1 or;
#!/usr/bin/env python
for default system python, although the latter is superfluous for the exercise.
According to this long thread (which was about Python 3.0, and the TextMate version existing back last spring, but I believe is still valid for Python 3.1 and today's TextMate), you can get it done (e.g. via #Ned's answer), but once you do many TextMate commands may well break (because they're written to use Python 2, and Python 3 is not backwards compatible with Python 2 -- for example, the use of reload, which disappeared in Python 3, is repeatedly mentioned in the thread). Still, it might work if you do not use or need much of TextMate's functionality (LaTeX typesetting for example was mentioned as something that totally breaks once you make TextMate use Python 3 instead of Python 2).
the shebang is the best solution, to see where python 3 is installed type in terminal:
which python3
you will get something like this:
/usr/local/bin/python3
if nothing shows up first install python3
and at the top of your script insert:
#!/usr/local/bin/python3
I wanted to achieve this in TextMate version 2.0.23 with the aim to use python3 as the default.
So this is how I could set the TM_PYTHON variable (based on #Ned Deily's answer above):
Open Textmate
Hit CMD + ; to open the settings
Now Add a new Variable with the + sign
4. In the Terminal.app I typed which python3 which gave me /usr/local/bin/python3.
Now whenever I open a python script and hit CMD + R it will execute as a pyhton3 script by default while "honouring" the installed PIP packages.

Categories