We Keep Coding

How can I tell if my Python Installation is "bundled"?

I'm installing a package (cx_Oracle), and the documentation says:
Make sure you are not using the bundled Python. This has restricted
entitlements and will fail to load Oracle client libraries.
I'm wondering: how do I tell if my Python installation (if I did not install it) is "bundled" or not?

Normally in MAC OS python comes along with installation of OS itself that means python package included in OS files also called as bundled python. You can check if the python you are using is bundled or not by
which python
On mac os
you should get output like if it's a bundled python
/usr/bin/python
when you want to get the path of externally installed python by
which python3
The only difference is
When you type
python
in terminal it launches pre-installed or bundled python.
If you type
python3
in terminal it launches externally installed python in this cases what the oracle documentation is recommended

coding python - need to set default interpreter without screwing up system

I am a newbie Python programmer. I am coding a simple application right now that just runs commands and prints the output in an organized way. Specifically, commands from FGLRX, the proprietary driver for ATI/AMD GPUs cards for linux.
One of the functions, is to get the device temperature. So far I got it working, but id like to make the output refresh automatically. I was advised to use the curses library.
Setting it up, I realized Im probably not running the best python system config.
Here is what happens:
I am running on Debian Wheezy. I am using the PyCharm Python IDE with project interpreter Python 3.3
So, first of all, when I try to debug within the IDE, it fails. I googled that, and thats because curses can not find a terminal within the IDE. - that's fine.
So I was trying to debug by just running "naturally" (per say) the program from Konsole.
I am not even sure what Python version my system is running. But it does not seem to be 3 because it fails to operate properly my program when using "elif".
But my biggest issue is the default subversion of python3 running. Its not the one I want.
Why do I say that:
running a python console within my IDE (3.2.3), I check for installed modules and both "curses" and "_curses" shows up as installed.
But, in my Konsole, if I run "python3 main.py", I get this:
audric#pc1:/mnt/megaomg/software/AmdAtiUtils$ python3 main.py
Traceback (most recent call last):
File "main.py", line 13, in <module>
import curses
File "/usr/local/lib/python3.4/curses/__init__.py", line 13, in <module>
from _curses import *
ImportError: No module named '_curses'
So apparently I am running 3.4 as default Python3 and it does not have curses installed?
My question here is what is my best option?
Set my default Python3 to 3.2.3?
Re compile 3.4 with curses?
go emo and go back to windows?
yet another option?
My goal here is to be able to run my program (obviously) but without compromising my system stability.
This is the program by the way:
https://github.com/audricd/AmdAtiUtils
Thanks in advance.

First, to know what is the Python version installed in your system, run in a terminal:
$ python --version
Second, curses are available on Python 3.4 standard library. Well, actually, as Documentation says:
The Windows version of Python doesn’t include the curses module.
So, if you are running your code on a Windows machine, you should read the documentation linked above to get one alternative.
Right, now your question. Some usual way to have a Python interpreter isolated from your system is using virtualenv. You can grab it from pip easily:
# pip3 install virtualenv
After, you can create a virtual environment in this way:
$ virtualenv venv
And it will generate a fresh interpreter for you isolated from your system Python binds (note that it will create a directory called venv). To activate it:
$ source venv/bin/activate
And now you can install all the necessary modules for your project without messing with your system (and perhaps with other Python code that you have).
Also, virtualenv lets you to specify the Python version which it will be based on. To do it, you should already have this specifc Python version installed on your system, and you need know where is its correspondent binary. So,you can do:
virtualenv venv --python=/the/python/binary/here
After you have set up virtualenv and have activated it, you can simple type:
python your_app.py
Now, your code will run with the Python version that you have set up with virtualenv.
You can get more on virtualenv on its documentation.
If you deliberately want to use a Python specific version and you don't have it installed on your system, download it from Python website and follow these instructions found in the Python README which is included in your donwload. If you need help, there is already many questions on StackOverflow related on how to install a new Python version without messing with your system.

#!/usr/bin/python and #!/usr/bin/env python, which support?

How should the shebang for a Python script look like?
Some people support #!/usr/bin/env python because it can find the Python interpreter intelligently. Others support #!/usr/bin/python, because now in most GNU/Linux distributions python is the default program.
What are the benefits of the two variants?

The Debian Python Policy states:
The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y. This ensures that a Debian installation of python is used and all dependencies on additional python modules are met.
Maintainers should not override the Debian Python interpreter using /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python.
Note that Debian/Ubuntu use the alternatives system to manage which version /usr/bin/python actually points to. This has been working very nicely across a lot of python versions at least for me (and I've been using python from 2.3 to 2.7 now), with excellent transitions across updates.
Note that I've never used pip. I want automatic security upgrades, so I install all my python needs via aptitude. Using the official Debian/Ubuntu packages keep my system much cleaner than me messing around with the python installation myself.
Let me emphasize one thing. The above recommendation refers to system installation of python applications. It makes perfectly sense to have these use the system managed version of python. If you are actually playing around with your own, customized installation of python that is not managed by the operating system, using the env variant probably is the correct way of saying "use the user-preferred python", instead of hard-coding either the system python installation (which would be /usr/bin/python) or any user-custom path.
Using env python will cause your programs to behave differently if you call them from e.g. a python virtualenv.
This can be desired (e.g. you are writing a script to work only in your virtualenv). And it can be problematic (you write a tool for you, and expect it to work the same even within a virtualenv - it may suddenly fail because it is missing packages then).

My humble opinion is that you should use the env-variant. It's a POSIX component thus found in pretty much every system, while directly specifying /usr/bin/python breaks in many occasions, i.e. virtualenv setups.

I use #!/usr/bin/env python as the default install location on OS-X is NOT /usr/bin. This also applies to users who like to customize their environment -- /usr/local/bin is another common place where you might find a python distribution.
That said, it really doesn't matter too much. You can always test the script with whatever python version you want: /usr/bin/strange/path/python myscript.py. Also, when you install a script via setuptools, the shebang seems to get replaced by the sys.executable which installed that script -- I don't know about pip, but I would assume it behaves similarly.

As you note, they probably both work on linux. However, if someone has installed a newer version of python for their own use, or some requirement makes people keep a particular version in /usr/bin, the env allows the caller to set up their environment so that a different version will be called through env.
Imagine someone trying to see if python 3 works with the scripts. They'll add the python3 interpreter first in their path, but want to keep the default on the system running on 2.x. With a hardcoded path that's not possible.

How to determine if Python is available in HPUX system?

How can I know if the environment that I am in (some version of HPUX) has python installed?

If python is in your PATH-Environment variable (if it is properly installed, it should be), you could use one of the following three:
python --version
which python
Whereis python
Calls python --version
Shows the path that is called when using python
Shows all paths to python
If you are unlucky, it is not in your PATH and you actually have to search the whole system to be sure it is not installed somewhere.
find / -name python

you can use the swinstall command to list installed packages:
http://www.bga.org/~lessem/psyc5112/usail/man/hpux/swinstall.1.html
and as #jacob said the which ,whereis and find commands are very usefull

python/serial broken in OSX lion / launchd

I have a launchd entry that worked with OSX 10.6 but that fails with 10.7. It uses python, and it produces an error whilst trying to import serial. I don't quite understand this, because I've re-downloaded pyserial-2.5 and re-installed it with sudo. (In desperation, I re-installed it for each of the many flavours of python on my machine.) As a test, I can enter python and do import serial without difficulties. Maybe there is a system path that is set up well for an interactive user, that is not set up for launched??
Can anyone suggest how I might diagnose the problem?

The path you are appending:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
is the site-packages directory for a third-party, non-system Python, possibly installed using a python.org installer, and not that of the Apple-supplied system Python 2.7, which would be:
/Library/Python/2.7/site-packages
So most likely you are using the python.org Python to install pyserial but are launching the system Python under launchd. Check your shell PATH (echo $PATH), it probably has:
/Library/Frameworks/Python.framework/Versions/2.7/bin
in it. And try which python. If you want to use the python.org Python with your launchd plist, modify it to use an absolute path to the right Python, for instance:
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
If you want to install pyserial with the system supplied Python, you can use an absolute path to it when doing the install:
/usr/bin/python2.7

Some experimentation with python -S showed me that the sys.path was not set up properly, so I solved the issue by
import sys
sys.path.append('/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages')
import serial
which I know is awkward, since it is so specific, but I guess I'll have to live with that, unless or until I can find a way to tell python where to find things, as it is being invoked from launched.
PS to anyone coming here later: the switch to OSX 10.7 (Lion) changed loads of things. Perhaps I had some initialization file somewhere, that I forgot about. If I find that, I'll try it that way, and post a further comment here.