You might be able to tell which hop is slow using something like pchar: http://stromberg.dnsalias.org/~strombrg/network-performance.html

Also, CPython having a GIL supposedly makes it easier to write C extension modules, which may be partially responsible for the large number of such modules for CPython.

Programs tend to be international out of the box, because str is what unicode used to be.

try/except is no longer a programmer trap.

map, filter and reduce are almost always better done as a generator expression or list comprehension, FWIW. I'm interested in hearing about Python and Functional Programming though.

Here's a list. See especially CFFI.

Python, as a plugin, would require adoption by Chrome, Firefox, Internet Explorer, Opera - I doubt all four of these would all agree to support Python as a plugin. However, it's possible to compile Python to javascript. Most of these transpile individual Python programs to JavaScript, but one, empythoned, actually compiles CPython 2.x to JavaScript using LLVM's JavaScript backend.

Tail recursion can be hard to debug - no stack frames to look back at.

Python the language definition, supports threads fine. CPython the reference implementation, supports threads, but while they work fine for I/O bound workloads, they are poor for CPU bound workloads. However, CPython supports multiprocessing, which uses multiple processes and shared memory; multiprocessing tends to give looser coupling between parallel code units than threading. Jython and IronPython support threads for both I/O bound and CPU bound workloads.

I've commented on python and whitespace enough times, that it became more practical to create a small web page about it: Read it here.

You're almost always better off using a generator expression or list comprehension instead of a lambda. Also, multiline lambdas detract from readability.

Python is duck typed - no need for interfaces, though it'd be nice to have them in pylint. Python has abstract classes. Python has a weak form of private members.

Rumor has it that patches were submitted for removing the GIL from CPython once, but they made uniprocessor workloads so much slower that the patches were rejected.

C: Overcomplicated, but fast, and useful for extending most other languages

Java: Reasonable, but a bit wordy. Pretty marketable. Performs quite reasonably really, though slow to exec

C++:Probably best avoided unless you have libraries in C++ you must use (in which case you could use Cython)

Objective-C: Useless, except on an iPhone

C#: Another lockin trojan horse from Microsoft. Avoid.

PHP: Awful design. Avoid.

BASIC: Those whom the gods would destroy, first they teach BASIC.

Python: Very nice language to work in. Sacrifices performance a bit in the reference implementation, but pretty fast if you use Pypy. Can be extended using C or Cython. Sometimes off-putting to people who feel that programming "should be complicated".

JavaScript: The assembly language of the web. It's a bit of a mess, but many, many web applications use it. There have been many projects attempting to translate other languages to JavaScript, to make web development less painful. One of them is Python, another is Java. I'd be surprised if there aren't others.

Perl:What a mess! It's much too kitchen-sink. For people whose problem domains aren't complicated enough to keep them entertained, so they need a messy language to make things more interesting.

Ruby:Popular among Java programmers who don't want to use anything but Java. Kinda perlish, but not quite as bad.