Python is good for quick prototyping and being a general purpose "glue" languge.
NumPy, SciPy, and extensions to other languages (eg C++) and packages (eg R, via RPy
Python 3.0 is not backward compatible with previous versions, as well as (I am told) these nice libraries like NumPy and SciPy. Publicly available libraries are a big plus, given that nothing (reliable) like this really exists in C++, with the possible exception of GSL for C.
Python doesn't have a built-in graphics, so one should use GNUPlot interface or Rpy, which are less convenient than Matlab or R graphics. There is a great package called matplotlib that basically ports all the 2D Matlab ploting functions with virtually verbatim syntax to Python. 3D plots like mesh and surf are not available at the moment (to my knowledge).
I think Python's biggest drawback is its Global Interpreter Lock (GIL). Not only is it confusing and unintuitive, if used incorrectly it virtually limits pure Python codes to be single threads. Of course as Joseph mentioned, you can interface Python with C++ very easily and have your parrallelizable computation code written in C++ with a Python wrapper. Doing so is pretty easy with SWIG and I think there are a few other ways out there as well (I recently stumbled upon a Boost library for doing so and it seems extremely well done and easy, but I have no experience with it)
Python supports multi-threading quite nicely. However, there is a significant issue related to multi-core support. The GIL (global lock) mentioned above effectively limits current versions of Python (including 3.0) to operating on one core at a time. Threads can share that core, but you can't have two python threads from the same process actively executing python code in true parallel fashion.
There are are several options for integrating Python and C++ code, and they can (with care) fully support python's native threading model. C++ routines called from python can also (with even more care) exempt themselves from the restricted parallel model by releasing the GIL and reacquiring it prior to returning to python. This allows a process running python to successfully orchestrate some serious, truly parallel number crunching implemented in C++. Only one core will be interpreting Python code at a time, but python threads running nested C++ calls can use any core available to the process.
There are a lot of packages that let you interface between python and C++ so what ends up happening is that you can use python to stick together components that are written in C++. I also find the QT wrapper for Python (PyQT) extremely useful and allows for all the advantages of QT and all the advantages of Python.
Some of my opinionated comments, and understand I am not a hard core coder:
-Perl is too esoteric for me
-Python is more similar to Ruby, but don't tell Ruby folks that
-If you hate indented white spaces, you will hate Python
-Sure, I use Python since I am lazy to use CINT
-Octave is fine, but NumPy and matplolib is fast 'enough' for me, YMMV
-Nice GUI's via matplotlib, chaco, MayaVI via Enthought
-I like Python since I can easily code, operating system agnostic
-Python is a good first OO computer language to learn
-Python is not the panacea, but one of many paths to pursue
-Don't use Python 3.0 yet.
-I'd be interested in hearing others using Python in Finance
A general but sad cycle for me:
1. Protoype in Python
2. Recode in C# naively not using any specialized .NET libraries
3. Look in shock at how big in size the C# code source is
4. Archive the C# code somewhere
5. Go back full time to the Python code
6. Hear from a friend on why I did not use XX .NET library a year later
7. Cannot figure out the old C# code since my documentation sucks
8. Continue to use the Python code.
Perl doesn't have Matlab's numerical capabilities. Perl isn't nearly as easy to interface with compiled code, has a much less clean synttax, and worst of all, the perl language community went crazy and has been bogged down trying to create perl6 for the last few years and basically getting nowhere.
I use Matlab for regression analysis, portfolio optimization, and low frequency trading models. Matlab has some superior functionalities. Get Octave if you don't have a Matlab license. There's QTOctave too if you need a graphical interface. Doesn't have a PDE solver like Matlab, but hey, there's your first project ;)
R project as a good and free analytic tool for prototype.
