Python: Есть ли способ предотвратить автоматическое преобразование из int в long int?

Python более строго типизирован, чем другие языки сценариев. Например, в Perl:

perl -E '$c=5; $d="6"; say $c+$d'   #prints 11

Но в Python:

>>> c="6"
>>> d=5
>>> print c+d
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot concatenate 'str' and 'int' objects

Perl проверяет строку и преобразует ее в число, а операторы + - / * ** работают с числами, как и ожидалось. PHP похож.

Python использует + для объединения строк, поэтому попытка выполнения операции c + d завершается неудачно, потому что c - строка, d - int. Python имеет более сильное понимание числовых типов , чем Perl. Хорошо, я могу с этим справиться.

Но подумайте:

>>> from sys import maxint
>>> type(maxint)

>>> print maxint
9223372036854775807
>>> type(maxint+2)

>>> print maxint+2
9223372036854775809
>>> type((maxint+2)+maxint)

>>> print ((maxint+2)+maxint)
18446744073709551616

Теперь Python будет автопродвигать с int, который в данном случае имеет длину 64 бита (OS X, python 2.6.1), на python long int, который имеет произвольный точность. Несмотря на то, что типы не совпадают, они похожи, и Python позволяет использовать обычные числовые операторы. Обычно это помогает. Это полезно, например, для сглаживания различий между 32-битной и 64-битной версиями.

Преобразование из int в long является односторонним:

>>> type((maxint+2)-2)

После преобразования все операции с этой переменной теперь выполняются произвольно. точность. Операции произвольной точности на порядок медленнее, чем собственные операции int. В сценарии, над которым я работаю, некоторые из них выполняются быстро, а другие из-за этого растягиваются на часы. Подумайте:

>>> print maxint**maxint        # execution so long it is essentially a crash

Итак, мой вопрос: есть ли способ запретить или запретить автоматическое продвижение Python int в Python long ?

Редактировать, продолжение:

Я получил несколько комментариев в форме «с какой стати вы хотите иметь поведение переполнения в стиле C?» Проблема заключалась в том, что этот конкретный фрагмент кода работал нормально на 32-битном языке C и Perl (с , используйте int ) с поведением переполнения C. Не удалось перенести этот код на Python. Различное поведение Python при переполнении оказывается (частью) проблемы. В коде смешано много разных идиом (C, Perl, немного python) (и смешаны эти комментарии), поэтому это было сложно.

По сути, выполняемый анализ изображения представляет собой дисковый фильтр верхних частот для выполнить аналогичное сравнение изображений. Часть фильтра верхних частот имеет целочисленное умножение двух больших полиномов. Переполнение было, по сути, логикой типа «все равно, это большое ...», поэтому результат был таким, как и предполагалось для переполнения на основе C. Итак, использование Хорнера Правило с O (n ² ) временем было пустой тратой, так как большие многочлены были бы просто «большими» - грубая форма арифметики насыщения карота.

Изменение полиномиального умножения на основе цикла на форму БПФ, вероятно, происходит значительно быстрее. БПФ выполняется за время, близкое к линейному, по сравнению с O (n ² ) для полиномиального умножения по правилу Хорнера. Это также ускорит переход от диска к оперативной памяти. Изображения не очень большие, но исходный код был написан в то время, когда они считались "огромными !!!" Владелец кода не совсем готов выбросить свой любимый код, так что посмотрим. «Правильный ответ» для него, вероятно, - просто оставить Perl или C, если ему нужен этот код.

Спасибо за ответы. Я не знал о десятичном модуле Python, и это, похоже, было ближе всего к тому, о чем я спрашивал - хотя в этом случае нужно решить и другие проблемы!