Python makes for much faster coding and debugging and works on many problems. But there's a whole range of contest problems bomb out in Python:

1) Large inputs or outputs and short time limits. Python's "print" statement is simply not fast enough for large-output problems.

2) Billions of booleans. In C++ you would use bitboards and bitarrays, maybe a 100MB worth. Using native Python data structures the memory can run into gigabytes. Using numpy, the bit-twiddling will still be many times slower.

3) Some problems with tight loops and a time limit is set at a couple times the speed of the author's C or Java solution. Python being 10x slower on such loops takes it over the time limit.

Google is for-profit? I thought it was just ad-supported...

I've been runing FAST ESP 5 clusters on RHEL for since 2008, used for web and site search. I found FAST ESP 5.2 especially to be terribly buggy on large deployments, and some issues their support never did resolve.

Moving to a unit that just needed to search a db, we ran ESP 5.3 for a year, but have now switched completely to Apache Solr. For searching records from a database, Solr does everything we need without gouging the company for $$$$$$ in annual support fees.

In just a few weeks we were able to set up a Solr cluster, integrate it using SolrNet, and tune Solr to produce excellent relevant results with very flexible matching. Relevance is excellent because we could tune Solr's ranking algorithm - FAST ESP was always a black box. Over about a week we tuned the parameters, and Solr now delivers better results than FAST ESP did on our data.

In Python, long comments are necessary in any public-facing code.
1) Due to the dynamic duck-typing, the docstring is the only place where you can explain to the world the exact structure and conditions of each parameter and the return value, especially if you are returning a dict that maps pairs of records to vectors.

2) The docstrings are where you put the doctests, which form an executable mini-unit-test and mini-tutorial for every public API. doctests also mean you have to write the code with few explicit dependencies (or spend most of the test lines mocking them out).

A 4-parameter public API function easily needs:

1 line (maybe 2) for description, followed by 1 blank line
+4*2 lines for the :type: and :param: descriptions
+2 lines for :rtype: and :return: descriptions
+5 lines or more for the >>> doctest lines
>=17 lines of comment per such function

Except in this case its like your dad is the son of the Judge and the "fine" is Death with a capital "D" (and quality time with some demons, like a normal jail, right?). Wait, except the Judge *is* the son too, and so is your dad. Uh oh.