Дешевая обработка исключений в Python?

Не потейте маленький материал. Вы уже выбрали один из более медленных языков сценариев там, таким образом пытаться оптимизировать вниз к коду операции не собирается помогать Вам очень. Причина выбрать интерпретируемый, динамический язык как Python состоит в том, чтобы оптимизировать Ваше время, не ЦП.

при использовании общеязыковых идиом, тогда Вы будете видеть все преимущества быстрой разработки прототипа и чистить дизайн, и Ваш код будет естественно работать быстрее, поскольку новые версии Python выпущены, и компьютерное оборудование обновлено.

, Если у Вас есть проблемы производительности, затем представьте свой код и оптимизируйте Ваши медленные алгоритмы. Но тем временем, используйте исключения для исключительных ситуаций, так как это сделает любой рефакторинг, Вы в конечном счете делаете вдоль этих намного легче строк.

Откладывая измерения производительности, которые сказали другие, руководящий принцип часто структурируется как, "легче спросить прощение, чем просят, чтобы разрешение" по сравнению с "посмотрело перед прыганием".

Рассматривают эти два отрывка:

# Look before you leap
if not os.path.exists(filename):
    raise SomeError("Cannot open configuration file")
f = open(filename)

по сравнению с

# Ask forgiveness ...
try:
  f = open(filename)
except IOError:
  raise SomeError("Cannot open configuration file")

Эквивалентный? Едва ли. Ose мультиберут системы. То, что происходит, если файл был удален между тестом для, 'существует' и 'открытый' вызов?

, Что происходит, если файл существует, но это не читаемо? Что, если это - имя каталога вместо файла. Может быть много возможных видов отказа, и проверка всех их является большой работой. Тем более, что 'открытый' вызов уже проверяет и сообщает обо всех тех возможных отказах.

инструкция должна быть должна уменьшить шанс непоследовательного состояния, и лучший способ для этого состоит в том, чтобы использовать исключения вместо теста/вызова.

"Кто-то может объяснить это мне?"

Зависит.

Вот одно объяснение, но это не полезно. Ваш вопрос происходит от Ваших предположений. Так как реальный мир конфликтует с Вашими предположениями, это должно означать, что Ваши предположения являются неправильными. Не большая часть объяснения, но вот почему Вы спрашиваете.

"Обработка исключений означает динамический вызов и статический возврат, тогда как, если оператор является статическим вызовом, статический возврат".

, Что делает "динамический вызов", средний? Поиск стековых фреймов для обработчика? Я предполагаю, что это - то, о чем Вы говорите. И "статический вызов" так или иначе определяет местоположение блока после если оператор.

, Возможно, этот "динамический вызов" не является самой дорогостоящей частью операции. Возможно, вычисление выражения оператора "if" является немного более дорогим, чем более простой "try-it-and-fail".

Оказывается, что проверки внутренней целостности Python являются почти тем же как Вашим оператором "if" и должны быть сделаны так или иначе. Начиная с Python, всегда собирающегося проверять, Ваш оператор "if" (главным образом) избыточен.

можно читать об обработке исключений низкого уровня в http://docs.python.org/c-api/intro.html#exceptions .

Редактирование

Главный: , если по сравнению с кроме дебатов не имеет значения.

, Так как исключения являются дешевыми, не маркируйте их как проблему производительности.

Использование, что делает Ваш код ясным и значимый . Не напрасно тратьте время на микрооптимизации как это.

С Python легко проверить, что различные возможности для скорости - узнают timeit модуль :

... сессия в качестве примера (использующий командную строку), которые сравнивают стоимость использования hasattr () по сравнению с попыткой/кроме протестировать на пропавших без вести и представить атрибуты объектов.

% timeit.py 'try:' '  str.__nonzero__' 'except AttributeError:' '  pass'
100000 loops, best of 3: 15.7 usec per loop
% timeit.py 'if hasattr(str, "__nonzero__"): pass'
100000 loops, best of 3: 4.26 usec per loop
% timeit.py 'try:' '  int.__nonzero__' 'except AttributeError:' '  pass'
1000000 loops, best of 3: 1.43 usec per loop
% timeit.py 'if hasattr(int, "__nonzero__"): pass'
100000 loops, best of 3: 2.23 usec per loop

Эти результаты синхронизации шоу в hasattr() случай, повышение исключения является медленным, но выполнение теста медленнее, чем не повышение исключения. Так, с точки зрения времени выполнения, с помощью исключения для обработки исключительный случаи имеет смысл.

РЕДАКТИРОВАНИЕ: параметр командной строки -n примет значение по умолчанию к достаточно большому количеству так, чтобы время выполнения было значимо. кавычка из руководства :

, Если-n не дан, подходящее количество циклов вычисляется путем попытки последовательных полномочий 10, пока общее время не составляет по крайней мере 0,2 секунды.

Я - новичок Python также. В то время как я не могу сказать, почему точно Обработку исключений назвали дешевой в контексте того ответа, вот мои мысли:

Примечание, что сверение if-elif-else должно оценить условие каждый раз. Обработка исключений, включая поиск обработчика исключений происходит только в исключительном условии, которое, вероятно, будет редко в большинстве случаев. Это - четкое увеличение эффективности. Как указано Jay, лучше использовать условную логику, а не исключения, когда существует высокая вероятность ключа, являющегося отсутствующим. Это вызвано тем, что, если ключ отсутствует большую часть времени, это не исключительное условие.

Тем не менее я предлагаю, чтобы Вы не волновались об эффективности и скорее о значении. Используйте обработку исключений для обнаружения исключительных случаев и условий проверки, когда Вы захотите выбрать что-то. мне напомнили о важности того, чтобы подразумевать под S.Lott только вчера.

Рассматриваемый вопрос:

def xyz(key):
   dictOb = {x:1, y:2, z:3}
   #Condition evaluated every time
   if dictOb.has_key(key):  #Access 1 to dict
        print dictOb[key]  #Access 2

По сравнению с [1 114]

#Exception mechanism is in play only when the key isn't found.
def xyz(key):
   dictOb = {x:1, y:2, z:3}
   try:
        print dictOb[key]  #Access 1
   except KeyError:
        print "Not Found"

В целом, имея некоторый код, который обрабатывает что-то, как недостающий ключ, на всякий случай обработка исключений потребностей, но в ситуациях как то, когда ключ не присутствует большую часть времени, что Вы действительно хотите сделать, должно решить, присутствует ли ключ => если еще. Python подчеркивает и поощряет говорить, что Вы имеете в виду.

, Почему Исключения предпочтены если-elif->

1. , Это выражает значение более ясно, когда Вы смотрите противник исключительный иначе необычные/неожиданные условия в Вашем коде.
2. Это более чисто и намного более читаемо.
3. Это более гибко.
4. Это может использоваться для написания более краткого кода.
5. Избегает большой противной проверки.
6. Это более удобно в сопровождении.

Примечание , Когда мы избегаем использования попытки - кроме, Исключения, продолжает повышаться. Исключения, которые не обработаны просто, переходят к обработчику по умолчанию. При использовании попытки - кроме можно обработать ошибку сами. Это могло бы быть более эффективно, потому что, если еще требует, оценка условия, при поиске обработчика исключений может быть более дешевой. Даже если это будет верно, то усиление от него будет слишком незначительно, чтобы потрудиться думать о.

я надеюсь, что мой ответ помогает.

Что статично по сравнению с динамическими вызовами и возвратами, и почему Вы думаете, что вызовы и возвраты несколько отличаются в Python в зависимости от того, если Вы делаете его в блоке попытки/кроме? Даже если Вы не ловите исключение, Python все еще должен обработать вызов, возможно повышающий что-то, таким образом, это не имеет значения к Python в отношении того, как вызовы и возвраты обрабатываются.

Каждый вызов функции в Python включает продвижение аргументов на стек и вызова вызываемого. Каждое функциональное завершение сопровождается вызывающей стороной, во внутренней проводке Python, проверяющего на успешное завершение или завершение исключения, и обрабатывает его соответственно. Другими словами, если Вы думаете, что существует некоторая дополнительная обработка, когда Вы находитесь в блоке попытки/кроме, который так или иначе пропускается, когда Вы не находитесь в одном, Вы ошибаетесь. Я принимаю то, об именно это Вы "статичный" по сравнению с "динамическим" различием были.

Далее, это - вопрос стиля и испытало разработчиков Python, прибывших для чтения исключения, ловящего хорошо, так, чтобы, когда они видят соответствующую попытку/кроме вокруг вызова, это было более читаемо, чем условная проверка.

Общее сообщение, как сказанный S.Lott, то, которые пробуют/кроме , не причиняет боль , таким образом, необходимо не стесняться использовать его каждый раз, когда это кажется соответствующим.

Эти дебаты часто называют "LBYL по сравнению с EAFP" †“, это, "смотрят перед прыганием" по сравнению с "легче спросить прощение, чем разрешение". Alex Martelli оказывает воздействие дальше на предмет здесь: http://mail.python.org/pipermail/python-list/2003-May/205182.html Этим дебатам почти шесть лет, но я не думаю, что важные вопросы изменились очень.