We Keep Coding

Is it possible to make my Windows Python installation aware of extra libraries it can use when running inside a Cygwin terminal?

I would like to use the following Python package, which requires ncurses: https://pypi.python.org/pypi/blessings
I have the Windows version of Anaconda Python installed, and designated as my Python distribution.
I have also have a Cygwin installation. When I run python -i within the provided Cygwin terminal, Anaconda Python starts up -- great!
If I then try import blessings, I'll get the following error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "A:\anaconda\lib\site-packages\blessings\__init__.py", line 5, in <module>
import curses
File "A:\anaconda\lib\curses\__init__.py", line 15, in <module>
from _curses import *
ImportError: No module named _curses
Alright, so what's happening is that Anaconda Python is understandably not picking up Cygwin's curses.
Now, does it even make sense to try and somehow make Anaconda aware of ncurses, only within the context of usage in a Cygwin terminal? I suspect it isn't, and that I am missing something conceptually?

You won't be able to use Cygwin Python's curses module with CPython unfortunately. Modules for the two Pythons are incompatible for the following reasons (and more):
Windows Python directly calls the Win32 API (via either the Visual Studio 2008, 2010 or 2015 C-Runtimes) while Cygwin Python links to the Cygwin POSIX API which is layered on top of the Visual Studio 6.0 C-Runtime. Mixing different C-Runtimes in a single process is a very bad idea: http://siomsystems.com/mixing-visual-studio-versions/, never mind further abstracted through a POSIX API.
Regardless of the C-Runtime differences, Cygwin implements the LP64 model while Windows implements the LLP64 model which would make the 64-bit size of long different between each, so some structures could be differently sized. They would likely be anyway due to #ifdefs in the code.
Is there any reason you can't use colorama?
The documentation for blessings suggests that should work.

Importing fortran files to python

This is a very newbie question, but after searching in Google for a while, I haven't been able to find a solution. I'm writing a Python code using Eclipse (in Linux Mint) which needs some routines written in Fortran 77 (the code is in a file named fortran_code.f). I've used f2py to get the file fortran_code.so. This file is in the same folder as the Python code (../workspace/python_project/src). The Python code only includes:
import fortran_code
a = 10
fortran_code.fortran_subroutine(a)
Once an again, the result is:
Traceback (most recent call last): File
"/home/user/Documents/workspace/python_project/src/Main.py", line 7,
in <module>
import fortran_code ImportError: /home/user/Documents/workspace/python_project/src/fortran_code.so:
undefined symbol: PyCObject_Type
The Fortran subroutine code is:
SUBROUTINE fortran_subroutine(a)
REAL*8, intent(in) :: a
REAL*8 b
b=a*2
end subroutine fortran_subroutine
To get the .so file (fortran_code.so) I use:
f2py -c fortran_code.f -m fortran_code
The version of f2py is 2. And the version of Python is 2.7.4
Any help to solve this problem would be very useful.
Thanks!

In order to make it work I had to modify the Python Interpreter from Python 3.2 to Python 2.7 (since f2py produces code for Python 2.7). After editing a new Python module everything worked fine!!!
Thanks for all suggestions and comments, which were really helpful.

ImportError: No module named MySQLdb - Debian 6.0

I got a problem in Python while try to import mysql. The beginning of my code is (I'm using monkeyrunner to run script) :
#!/usr/bin/env python
import sys
import MySQLdb
.
.
.
etc
Each time I try to run the code, I got the current error:
dani#debian:~/public/Yandex Maps Test$ monkeyrunner test.py
130413 00:49:22.066:S [main] [com.android.monkeyrunner.MonkeyRunnerOptions] Script terminated due to an exception
130413 00:49:22.066:S [main] [com.android.monkeyrunner.MonkeyRunnerOptions]Traceback (most recent call last):
File "/home/dani/public/Yandex Maps Test/test.py", line 4, in <module>
import MySQLdb
ImportError: No module named MySQLdb
130413 00:49:22.066:S [main] [com.android.monkeyrunner.MonkeyRunnerOptions] at org.python.core.PyException.fillInStackTrace(PyException.java:70)
.
.
.
etc
I tried to re-install mysql for python:
sudo apt-get reinstall python-mysqldb mysql-server
But nothing helped. Any ideas or tips?
Regards,,,

The problem is that monkeyrunner isn't the same interpreter as your default system Python, and doesn't share the same site-packages, etc.
That #!/usr/bin/env python at the top of your script is misleading. If you actually run your script with /usr/bin/env python test.py, or just ./test.py (assuming chmod +x), it will work. But you're not, you're running it with monkeyrunner.
So, nothing you install for your system Python is going to be usable within monkeyrunner. You have to install it for monkeyrunner instead.
Moreover, as the docs say:
The monkeyrunner tool uses Jython, a implementation of Python that uses the Java programming language.
While Jython is Python, and implements the same Python language and (almost) standard library as CPython, it doesn't implement the CPython C API, and therefore can't use C-API extensions like MySQLdb. (They're actually working on a clever wrapper that will change this in the future, but that doesn't help you today.)
There are other MySQL drivers that work with both CPython and Jython (because they use pure Python), such as PyMySQL. But the simplest solution is to just use Java's JDBC drivers. As the Jython FAQ suggests, the easiest way to do that is:
Use zxJDBC which gives data database connectivity from Jython using the Python DB API 2.0 interface…
Unlike using JDBC directly, using zxJDBC often means you only need to change one line in your MySQLdb code to make it work.

i have the same question with u.
and i tried to use zxJDBC to fix it.
but when i run the script, it cannot find "org.gjt.mm.mysql.Driver" either "com.mysql.jdbc.Driver". Even i put mysql-connector-java-5.1.34-bin.jar and zxJDBC.jar under system CLASSPATH.
i tried run this script under jython. it worked.
so i think this question is related with monkeyrunner.

sys.path.append doesn't work with Python 3.x

I have Blender 2.66a which is an application that offers Python 3.3 APIs, On my system I have an installation of Python 3.2 with several modules that I wish to use inside Blender, I tried both
sys.path.append(r"/usr/lib/python3.2/")
sys.path.append("/usr/lib/python3.2/")
and this commands gives no errors, infact even the autocomplete feature works and new modules are indexed, so i tried
import tkinter
but this generates the following error
Traceback (most recent call last):
File "<blender_console>", line 1, in <module>
File "/usr/lib/python3.2/tkinter/__init__.py", line 42, in <module>
raise ImportError(str(msg) + ', please install the python-tk package')
ImportError: No module named '_tkinter', please install the python-tk package
and I don't get the point of this error because it fails to load a module that it's there asking me to install the same module because that module is not installed ( ? ).
What can cause this obscure problem ?
EDIT
the tkinter module works from the gnome-terminal

If I got you right, you're using Python 3.3 from Blender but try to include the 3.2 standard library. This is bound to give you a flurry of issues, you should not do that. Find another way. It's likely that Blender offers a way to use the 3.3 standard library (and that's 99% compatible with 3.2). Pure-Python third party library can, of course, be included by fiddling with sys.path.
The specific issue you're seeing now is likely caused by the version difference. As people have pointed out in the comments, Python 3.3 doesn't find the _tkinter extension module. Although it is present (as it works from Python 3.2), it is most likely in a .so file with an ABI tag that is incompatible with Blender's Python 3.3, hence it won't even look at it (much like a module.txt is not considered for import module). This is a good thing. Extension modules are highly version-specific, slight ABI mismatches (such as between 3.2 and 3.3, or two 3.3 compiled with different options) can cause pretty much any kind of error, from crashes to memory leaks to silent data corruption or even something completely different.
You can verify whether this is the case via import _tkinter; print(_tkinter.__file__) in the 3.2 shell. Alternatively, _tkinter may live in a different directory entirely. Adding that directory won't actually fix the real issue outlined above.

import serial error occured in Python

I wrote
import serial
There message are occured.
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/serial/__init__.py", line 20, in ?
from serialposix import *
File "/usr/lib/python2.4/site-packages/serial/serialposix.py", line 13, in ?
import sys, os, fcntl, termios, struct, select, errno
ImportError: No module named termios
What's wrong?

termios has been in the Python standard library since 2.0 at least (I'm not very familiar with older Python versions), but it's always been a Unix-only module. Your 2.4 should be fine, IF you're running under any Unix flavor -- i.e., anything but Windows, more or less. The problem you're seeing suggests either a faulty Python install, or that you're on a non-Unix platform (and if it's not Windows I'm very curious to learn what it IS).
Edit: OP has clarified that they're on Debian -- which has a long history of removing some crucial pieces from upstream components and hiding them in hard-to-locate packages, a history that has long hurt their Python packaging in particular.
I tried several package search engines but I can't find out where they hid termios for Python in particular (for any version) so all I can suggest are workarounds (unless the debian tag I just added attracts debian experts who can help) as well of course as asking on debian-specific forums (clarifying exactly what versions are in use, of course).
Maybe installing another Python (a REAL Python, not the "cleverly packaged", i.e. mangled into pieces and with pieces missing, Debian travesty) might help -- for example, if both sticking with Python 2.4 and using .deb are important constraints to the OP, PYTHON2.4_2.4.6-1UBUNTU3_I386.DEB (not sure how cleanly it and its dependencies install on the OP's specific Debian version, of course); or else, one might as well go with a more recent and complete Python, see for example here (specifically for Debian Etch, but hopefully it can be adapted for the OP's exact version).