Когда использовать отладчик Python
Поскольку Python - это динамический интерпретируемый язык, вам не нужно компилировать код перед его запуском. Следовательно, очень легко просто написать свой код, запустить его, посмотреть, какие проблемы возникают, и исправить их. Использование горячих клавиш или макросов может сделать это невероятно быстро.
Итак, поскольку так легко сразу увидеть вывод вашей программы и любые ошибки, которые могут возникнуть, я еще не использовал инструмент отладчика. В каких ситуациях может потребоваться использование настоящего отладчика по сравнению с методом, который я использую в настоящее время?
Я хотел бы знать, прежде чем попаду в ситуацию и расстроюсь, потому что не знаю, как решить проблему.
Ответы 6
Каждый раз, когда вы хотите проверить содержимое переменных, которые могли вызвать ошибку. Единственный способ сделать это - остановить выполнение и взглянуть на стек.
pydev в Eclipse - довольно хорошая IDE, если вы ее ищете.
Я использую pdb для базовой отладки Python. Вот некоторые из ситуаций, в которых я его использую:
- Когда у вас есть цикл, повторяющий более 100000 записей, и вы хотите прервать его в определенной точке, это становится действительно полезным. (Условные разрывы)
- Отслеживайте поток управления чужим кодом.
- Всегда лучше использовать отладчик, чем засорять код отпечатками.
- Обычно может быть более одной точки отказов, приводящих к ошибке, на первый взгляд не все они очевидны. Итак, вы ищите очевидные места, если там все в порядке, вы продвигаетесь вперед и добавляете еще несколько отпечатков ... здесь отладчик может сэкономить ваше время, вам не нужно добавлять печать и запускать снова.
Обычно, когда ошибка кроется в какой-то функции, но я не знаю, что именно и где. Либо я вставляю десятки вызовов log.debug() и затем возвращаю их обратно, либо просто вставляю:
import pdb
pdb.set_trace ()
а затем запустите программу. Отладчик запустится, когда достигнет этой точки, и предоставит мне полный REPL, чтобы я мог его найти.
За 30 лет программирования я использовал отладчик ровно 4 раза. Все четыре раза нужно было прочитать файл core, созданный в результате сбоя программы C, чтобы найти скрытую там информацию трассировки.
Я не думаю, что отладчики сильно помогают даже в компилируемых языках. Многим нравятся отладчики, я уверен, что для их использования есть несколько причин, иначе люди не проявили бы к ним такой любви и заботы.
Вот в чем суть - программное обеспечение - это сбор знаний.
Да, он должен работать. Что еще более важно, программное обеспечение имеет смысл.
Это не обвинение в использовании ваш отладчика. Тем не менее, я считаю, что люди, которые полагаются на отладку, иногда создают действительно странно выглядящий код, и у них не будет веского оправдания тому, что это средства. Они могут только сказать: «Это может быть взлом, но он работает».
Мое предложение по отладчикам - «не беспокойтесь».
"Но что, если я полностью озадачен?" Вы спросите: "А стоит ли мне тогда изучить отладчик?" Совершенно озадачен чем? Язык? Python слишком прост, чтобы вводить в заблуждение. Какая-то библиотека? Возможно.
Вот что вы делаете - с отладчиком или без него.
- У вас есть источник, прочтите его.
- Вы пишете небольшие тесты для проверки работы библиотеки. Если возможно, с помощью интерактивной оболочки. [Кажется, что все действительно хорошие библиотеки демонстрируют свои возможности в интерактивном режиме Python - я стремлюсь к этому уровню жесткой, ясной простоты.]
- У вас есть исходник, добавьте функции печати.
Я согласен, что отладчик не замена мозгу, но и обратное. Конечно, сначала нужно подумать о проблеме. Но во многих случаях хороший отладчик позволяет проверить вашу гипотезу намного быстрее, чем любой другой метод.
@Kena: Я считаю, что в Python это не так. Интерактивный Python настолько прост в использовании, что отладчик кажется излишним.
Что ж, я не совсем уверен, где провести грань между отладчиком и интерактивной консолью. В моей книге это все, что связано с «выяснением того, почему этот код не выполняет то, что должен делать», независимо от того, вызываю ли я фрагмент прямо в консоли или запускаю консоль в ключевой момент с помощью pdb. Мне просто нравится второй вариант больше из-за тех ошибок, с которыми я сталкиваюсь, но все, что работает для вас ...
I don't think debuggers help much, even in compiled languages. Когда-нибудь пробовали C++?
@ S.Lott Я думаю, что суть вашего ответа заключается в том, что программные системы, предназначенные для тестирования, обычно не требуют использования отладчика, поскольку, если что-то не работает согласно спецификации, модульный тест должен завершиться ошибкой. Запретив это, вы включаете ведение журнала, выясняете, что происходит, а затем пишете тест для обнаруженной ошибки, а затем исправляете ошибку. Фактически, единственный раз, когда я действительно нашел полезный отладчик интерактивный, был когда я пытался исправить графические пользовательские интерфейсы, например, используя firebug в Firefox.
@Lanaru Когда-нибудь пробовали отлаживать многопоточную систему C++ в отладчике? Забудь это. Использовать ведение журнала: stackoverflow.com/a/6168353/71074
Я считаю очень полезным обратиться к отладчику в случае неудачного теста.
Я добавляю import pdb; pdb.set_trace() непосредственно перед точкой отказа теста. Тест запускается, создавая потенциально довольно большой контекст (например, импортируя фикстуру базы данных или создавая HTTP-запрос). Когда тест достигает строки pdb.set_trace(), он попадает в интерактивный отладчик, и я могу проверить контекст, в котором происходит сбой, с помощью обычных команд pdb в поисках подсказок относительно причины.
Возможно, вы захотите взглянуть на этот другой пост SO:
Почему отладка лучше в среде IDE?
Это напрямую связано с тем, о чем вы спрашиваете.
Я полагаю, вы имели в виду, почему отладчик полезен для профессионалов, но отладчик может быть полезен также для объяснения семантики языковых конструкций. Тонни (thonny.cs.ut.ee) здесь хорошо справляется.