I'M trying to find the python3 file that would be the counterpart to the python3.exe in Windows. I want to point Geany to pyton3 rather that 2.7 which it's pointing to now. I don't even know if I found the right directory or not but I've attached a screenshot from /usr/bin, there are 3 python3 files. It's going to take some getting use to in Linux, in Windows this was easy > Program Files > Python > python3.exe. Thanks for any help and advice on how this typically works in Linux

Recommended Answers

All 5 Replies

You need to show how the files are linked: ls -l /usr/bin

In any case, the files python3 and python3.2 are the executables you need to run. If the raw /usr/bin/python is not linked to one of those, you can change that easily enough.

Another way is to open up a command line and use the which command.
The which command will tell you the path of an executable.
So if you want to find out which python3 executable is being used you would simply use:
which python3. This will output the path to the python3 executable (or it might be a symbolic link). As Rubberman has said, this will almost certainly be in /usr/bin.

If you're ever unsure where an executable is located; as long as it is somewhere in a directory specified in the system $PATH environment variable, you can use the which command. Once you've got the path, you can open up that directory and use ls -l to see whether it is a symbolic link to another executable file, or if it is the actual executable itself.

I'm not sure about changing the raw /usr/bin/python to point to python 3 though because python is integrated into most, if not all distros. And AFAIK, all distros ship with python2.x by default (usually 2.6 or 2.7 nowadays). I don't think any use python3 as the default yet. So /usr/bin/python is usually linked to python2.
I'd guess that changing /usr/bin/python to point to the python3 executable could cause any system scripts/programs which use python2.x syntax to fail because they'd end up being ran by the python3 interpreter. So I don't think that is the way forward.

On the subject of using python 3 with geany, a quick search has yielded this:

To keep the content on-site/local; basically as root, use your favourite editor to edit the file /usr/share/geany/filetypes.python
e.g. using vim on a debian based distro:
sudo vim /usr/share/geany/filetypes.python

Then use # to comment out the last two lines in the file and add the following lines:
compiler=python3 -c "import py_compile; py_compile.compile('%f')"
run_cmd=python3 "%f"

Finally save the file and exit your editor and you're set up. Apparently that will allow you to use Geany as a Python3 IDE.

-rwxr-xr-x 3 root root 7149032 Aug 12 18:04 python3
-rwxr-xr-x 3 root root 7149032 Aug 12 18:04 python3.2

What's the difference between these two? I got the with ls -l /usr/local/bin

Hmm, that's strange, it looks like they are identical and are both executables.
python3.2 should be the actual python executable and python3 should be a symbolic link which points to the python3.2 executable.

What distro are you running ATM?

Using ls -l /usr/bin/python* yields the following results for me (Kubuntu 12.04):
/usr/bin/python -> python2.7
/usr/bin/python2 -> python2.7
/usr/bin/python3 -> python3.2
/usr/bin/python3.2 -> python3.2mu
/usr/bin/python3mu -> python3.2mu

NOTE: I've snipped all of the file-permissions, owner/group, filesize, timestamp information as it is irrelevant. The files with arrows '->' next to them are symbolic-links (or symlinks for short).

Looking at my results you can see that /usr/bin/python is a symbolic link to the python2.7 executable (/usr/bin/python2.7). So the system-wide, default version of python used by my system is python2.7. Therefore any time a program tries to start python by opening /usr/bin/python (or just 'python'), python2.7 will be used.

The /usr/bin/python2 symlink is also set up to use python2.7, so any applications which start python by opening /usr/bin/python2 (or 'python2') will also use python2.7

Then there are several symlinks set up which point to the python3.2mu executable.
So any programs using /usr/bin/python3, /usr/bin/python3mu, or /usr/bin/python3.2 will end up using the python3.2mu executable.

Basically, the symlinks allow you to update/upgrade your python executables to new versions without having to reconfigure all of the programs that need to use the python interpreter.

So if you have a program which requires any version of python2.x (or any version of python3.x), it will be set up to start python via the python2 (or python3) symlinks. So whatever version of python is associated with that symlink will be used by that application.

If an application requires a very specific version of python (e.g. Blender, which currently requires v3.2) then it uses a more specific symlink (e.g. /usr/bin/python3.2)

With this setup, if your distro adopts a later version of 2.x or 3.x as its default, the new version of the python executable will be installed. To ensure that all of your applications can access the new version, if appropriate, the symlinks are updated to point to the new version.

Without the symlinks, each time you updated python to a new version, you'd have to reconfigure all programs that use python to use the appropriate version.
So it just makes updating to a new version of python easier.

So for example, if the Ubuntu repositories suddenly switch to python3.3 as the default version of python3; when I update my system, the python3 and the python3mu symlinks will be updated to open the newly installed python3.3 executable. The python3.2 symlink, which is used by Blender will not be affected and will still point to the python3.2mu executable until Blender requires a later version of python.

Symbolic links are extremely useful when you have to manage several different versions of a particular program (like python) which are installed simultaneously alongside each other.

BTW, regarding your geany problem:
Have you tried the instructions I posted in my last post?

Thanks Jason, I finished it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.