TL;DR Конкретно для спортивного программирования CPython (стандартный интерпретатот Патона) медленный, PyPy в несколько раз быстрее CPython, но оба всё еще проигрывают C++.

Почему CPython "так плох"?

CPython — это интерпретатор, что значит, что при каждом запуске программы ему приходится токенизировать исходный код, потом строить AST и т.д. — помимо непосредственно выполнения программы. Уже из-за одного этого факта получаем время старта предельно простой программы на Python примерно на уровне 20мс — не очень много, но не прям "незаметно" (особенно на фоне TL в, скажем, 100мс). Как только мы подключаем какой-то модуль — скажем, import itertools — незамедлительно получим увеличение времени старта на 10-15мс. Это не касается модулей, написаных на Си (math, к примеру) — их подключение влечёт увеличение времени выполнения в худшем случае на пару милисекунд.

Кроме того, с точки зрения интерпретатора, любая переменная (даже примитив — число или булево значение) является объектом. Даже функция! А для объекта приходится хранить и ссылку на тип, и ссылку на непосредственно данные, и много-много прочего. Целое число "0" занимает 24 байт в CPython, целое "1" — уже 28 (как и любое другое натуральное число до 2**30 - 1). Очевидно, что это немыслемое расточительство, поэтому в CPython хранится таблица с использованными значениями целых чисел — что значит, что если у вас недавно уже была где-то "77" в качестве результата чего-либо, то новая "77" будет ссылкой на тот же объект. Получается, что памяти на "старые" числа мы используем поменьше (ну, как указатель 32/64-битный указатель), но жертвуем при этом быстродействием — нам ведь для каждого нового числа придётся искать в таблице "а не было ли у нас уже такого числа". Реализация, само собой, отличается от "просто таблицы" — но это не существенно. Важно, что это спортивному программисту мало помагает.

Очевидно, что, работая с объектами, нам еще и приходится мириться с дополнительными расходами на работу с ними — к примеру, посчитать 1 + 2 — значит вызвать метод объекта для суммирования с другим объектом. А поскольку оба имеют тип int, то мы получим еще и дополнительные проверки "а длинное ли это число?", "а при суммировании не получится ли длинное число?" — спасибо нативной длинной арифметике :)

Можно приводить еще очень много примеров особенностей — от генерации range(n) списка из n чисел (UPD: касается Py2) до необходимости проверки существования оператора [] при каждом обращении к list — что особенно больно при наличии чего-то вроде двумерного списка.

Каким образом решает проблему PyPy?

Всё достаточно просто. Во-первых, PyPy не интерпретирует программу — он её, фактически, компилирует на лету (JIT). Из-за этого время старта у PyPy еще больше, чем у CPython. Лично у меня на ПК время запуска достаточно простой программы составляет примерно 150мс, а подключая тот же itertools — так и вовсе 210мс.

Однако, эта "100-милисекундная слабость" компенсируется действительно возросшим в разы быстродействием в обычных для спортивного программирования операциях. К примеру, $$$\sum_{i=1}^{10^8} (1 + 1/i)$$$ считается 20 секунд на CPython и "всего" 1.2с на PyPy. А вот, скажем, $$$\sum_{i=1}^{10^6}(gcd(i, \lfloor \frac{n}{i} \rfloor ))$$$ уже не настолько радует — 255мс PyPy против 474мс (но тут у PyPy половина времени ушла реально на запуск).

Если что, код вот:

n = int(input())

n = 10**n

res = 0

def gcd(a, b):
    while a:
        a, b = b%a, a
    return b

for i in range(1, n):
    res += gcd(i, n//i)

print(res)

Что там с делением по модулю

Есть подозрение, что программа использовала деление по модулю в контексте "вывести остаток от деления ответа на 10^9 + 7". Если так, то тут у C++ явное преимущество, и вот почему. Прежде всего, по моему скромному опыту, операция умножения в несколько раз дешевле операции деления/взятия по модулю. Кроме того, просто посмотрите, как gcc оптимизирует деление по модулю при флаге компиляции -О2 — там нет никакого деления, только умножение! А если вместо 1'000'000'009 у нас вдруг степень двойки — то компилятор и вовсе оставляет всего лишь один "AND". Пайтон такого не умеет — у него, увы, умножение — всегда умножение (а никак не битовый сдвиг), а деление — всегда деление.

У С++ (как и у любого компилируемого языка) в спортивном программировании есть огромная фора — время компиляции никак не учитывается в оценивании (кроме того, что оно не должно превосходить условных 20 секунд — но это уже целая вечность!). Та оптимизация, которую я привёл — лишь одна из многих, которые компилятор способен сделать еще до запуска программы. Выкидывать вызовы функции, разворачивать циклы и многое другое — этого не сделаешь на лету за 100мс при интерпретации программы, как бы не хотелось.

По поводу медвежьей услуги... Я скажу очевидное: тут очень тонкий вопрос. На UOI существование решения на Python не гарантируется, это с одной стороны. С другой — заставлять переходить "питонистов" на C++ перед олимпиадой, принуждая набивать шишки на новом языке и потенциально создавать вероятность провала на олимпиаде из-за плохого знания тонкостей языка (а у плюсов их, очевидно, хватает) — тоже не очень бы хотелось.

A little bit off topic:

Once I was interested how to speed up python and googling something like "how to speed up python" helped to learn some basic rules (this is not the link I found back than) like:

• do not += string
• do not reinvent wheel
• keep namespace clean
• high order functions sometimes work faster than loops

Following this gave another insignificant 0.01 improvement over previous result.

IMHO people who use python for CP should make sure they know basic differences between Py3 and Py2 (e.g. never in Py2

for i in range(10**9): 
 if i % 2 == 0:
    break

)

The main problem with p̶a̶s̶c̶a̶l̶ python to my mind is absence of STL, in UOI probably it is less significant but in ACM it is crucial. On the other hand, long arithmetics in PY3 is for free.
And in some regions of ACM ICPC judges provide solutions in python, so looks like it is starting to be trendy in CP also. Another interesting thing is that Kotlin is also fast to write, though slow to work.