How to set Python IDLE to use certain python version - python-3.x

I am using Windows 8.
Python version 2.7.3 have been installed on my computer together with another software.
Now I have installed python 3.3.5 and i want to use this version from now.
But everytime I run Python IDLE it runs version 2.7.3.
Even if I go to C:\Python33\Lib\idlelib\idle.pyw and run idle.pyw it runs with the 2.7.3 version.
I thought that every python version install its own IDLE so I am quiet confused here.
When I run Hello world program from the console it runs using the version 3.3.5 I have checked that.
So what I need to do is to run IDLE using 3.3.5 version
Anybody knows what to do?

Each installation of Python comes with its own respective version if IDLE. I suggest you explore your Python installation folder, and find the version of IDLE you're looking for and create a shortcut to it, or add it to your environment variable list, so you can invoke a specific version from the command line.

Related

Visual Code gives error that it cannot find Python on Mac Pro

I'm running a Mac Pro 2021 model version 12.6. For some reason, my vscode will not run Python anymore when I tried using a program. I switched over to the cloud-based version for a while and now switched back to the application. It says that it could not find Python in my files. I believe both VSCode and my Mac are updated up to date. I installed python 3.11.0 for Mac, but no progress. I also tried running the update shell.command and the certificate commands as a part of the download in the vscode terminal, but it did not help. I also reinstalled the Python
v2022.16.1 Vscode extension and restarted the program. I still get the same error.
Explained above.
Have you tried Shift + Command + P type "Python: Select interpreter" yet?
Usually, all installed Python interpreters show up here, and you can also enter a path to a Python interpreter on your system.

Can’t make python work in conda environment (GLIBC not found)

I'm trying to set up a conda environment with python 3.6 on a remote server working on CentOS. The installation goes well, but once I try to execute python I get the following message python: /lib64/libc.so.6: version 'GLIBC_2.15' not found. I noticed that for other python version older than 3.4 this doesn't happen.
Given this, I tried installing glibc before python, but after installing python 3.6 and trying to run it, now I get Segmentation fault (core dumped).
Note that I don't have permissions to update conda and that the version the server is using is 4.4.7, so I haven't tried updating it. However, I had previously set an environment without any problem. After I tried to install a package my jupyter notebooks wouldn't work so I removed the environment.
What would be the new system and the old one.
The old system -- the remove server running CentOS, has GLIBC that is older than 2.15.
The new system -- the one on which your Python 3.6 was compiled, used GLIBC-2.15 (or newer).
You need to either find a Python 3.6 build which is targeted to your version of CentOS, or you need to compile one yourself on a system with GLIBC matching whatever is installed on your remote server.
P.S. Saying "server running CentOS" is like saying "system running Windows" (i.e. not saying much). Which version of CentOS?

Showing python 2.7.12 for python 3.9.1 on Command window?

I am using python 3.9.1 on my computer and when I try this command on cmommand windows : python -- version , I come up with 2.7.12 !!! And it does not show the version correct.
I uninstalled python and removed all the related files on C drive as well as environmental Variables...
Now I don't have python but it still shows the version 2.7.12 when I ask for Command windows!!!
Does anyone know what is the problem ????
if you have both versions then you should write python2 --version o
Go to my computer, right click and then properties. Here go to Advanced System setting
and at the bottom of the window open Environment Variables and check any variable having python on it. if there are two variable maybes this is the problem.
Also go to the app data on your windows and check files if there is a file related to the older version of python.
Good Luck.
You can use PowerShell instead of cmd as well try this one after checking the variables.

how to verify whether latest python version installed properly

when I try to check python version in Centos7 by typing command
1) python --version
-bash: /usr/local/bin/python3.6: No such file or directory
OR
2) which python
"alias python='/usr/local/bin/python3.6'.
Could anyone explain me why it shows like this instead of showing python version?
Thanks.
In order to sum up, for future people who will look in this question:
when installing different versions of python on linux using package manager (in this case yum because you are using CentOS, but it might be apt or something else) linux installs the side-by-side, meaning you have all of the versions installed together.
If you want to use a specific version other than your linux distribution diffault one you need to call it explicitly (i.e. python3.6 or python3.8)
Make sure you are looking for the wanted python version on the right path.
When you want to run some version of python after installing it I suggest you to just write python in the bash and just hit tab+tab and the bash will suggest all the installed versions in the $PATH.

Anaconda Python for Gurobi 6.0.4 installation _Py_FalseStruct error

In order to run an optimization problem we set up Gurobi 6.0.4 together with
Anaconda (Version 2.2.0) Python (Python 2.7.9.) on
Linux CentOS release 6.6 (Final) with the 2.6.32-504.16.2.el6.x86_64 Kernel
Following the installation guidelines of Gurobi (listed here: http://www.gurobi.com/documentation/6.0/quickstart_linux.pdf)
everything worked out in the first step. Gurobi was installed, could obtain a license. Also the PATH variables have been set (in the .bashrc) according to the manual, with a little extension for the referal to anaconda python (and not the other local Versions of python (being 2.7 and 3.4):
export GUROBI_HOME="/opt/gurobi604/linux64"
export PATH="${PATH}:${GUROBI_HOME}/bin:${PATH}:opt/anaconda/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"
Following the procedure we executed: python2.7 setup.py install in the respective directory /opt/gurobi604/linux64. After this usually you could run the import gurobipy command in the python interpreter wihtout errors. For older Versions of Gurobi (as 5.6.3) this works out very well.
For 6.0.4 though we constantly receive the error:
ImportError: /opt/anaconda/lib/python2.7/site-packages/gurobipy/gurobipy.so: undefined symbol: _Py_FalseStruct
This is very reproducible, no matter if we put anaconda also in the global path, and check the bash for any overwriting of the environment variables, which is not the case.
On Windows 8 the Gurobi 6.0.4 and Anaconda Python 2.2.0 work together without any problems.
Also applying hints from here: Python Module Error on Linux did not work out.
Did anyone else experience these problems with this tooling combination? thx.
The error message indicates that you use the Python module for version 3.4 in your Python 2.7 package directory. This can happen if you do not clean your Python module build directory between builds. Please try the following:
Completely remove the 2.7 package from your Python 2.7 installation (e.g. remove /opt/anaconda/lib/python2.7/site-packages/gurobipy)
Completely remove the Python module build directory from your Gurobi installation (e.g. /opt/gurobi604/linux64/build)
Re-run the build process for the Python 2.7 module (e.g. run "python2 setup.py install" in /opt/gurobi604/linux64)
Please note that CentOS is currently a non-supported platform for Gurobi.
Thank you for the hint, I think we tried that, but did not finish the procedure in this way. We tried to clean the system but in that particular case still hat both python Versions (due to other applications that use 3.4) on the machine. Our solution in this case was just to reinstall everything clean on a Ubuntu 14.04 VM. Since then no further problems occured. (I know not the cleanest solution.)
We had some similar issues when we updated to Gurobi 6.5, but that could be solved when corrctly addressing the usual path issues.
Thank you in any case for the reply, I think this really will help us with the next, then clean deployment :-)

Resources