Как избежать использования отладочных операторов print / pdb в приложениях с открытым исходным кодом Python, когда вы отлаживаете их и просто заканчиваете работу?

Question

Иногда при разработке с использованием программного обеспечения с открытым исходным кодом вам необходимо прочитать его исходный код (особенно zope / plone). Часто мне нужно написать операторы печати, отладочные вызовы (import pdb) или комментарии try / Кроме предложений, вы называете это.

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

Итак, мой вопрос: как вы себя организовываете, когда делаете это? Пишите ли вы «TODO» вдоль модификаций и выполняете ли вы их поиск позже, оставляете ли вы все открытым в своем редакторе, и когда вы находите то, что искали, просто возвращаете файлы (этот подход бесполезен, когда вы ищете действительно большая проблема, которая требует дней, вам нужно выключить компьютер и вернуться на днях)? Или вы просто ничего не делаете, так как операторам print в среде разработки не о чем беспокоиться?

Я использую Vim. Мне просто интересно узнать, как другие программисты относятся к этой проблеме.

Answer 1

Я часто сталкивался с этой проблемой. Теперь, как часть моего процесса регистрации, я запускаю комбо-скрипт find / grep, который ищет мои отладочные операторы. Единственное предостережение в том, что я должен сохранять согласованность своих добавленных операторов отладки, чтобы grep мог найти их все.

как то так:

## pre-checkin_scan.bin
find . -name "*.py" -exec grep -H --file=/homes/js/bin/pre-checkin_scan_regexp_list.grep {} \;



## pre-checkin_scan_regexp_list.grep
## (The first pattern is to ignore Doxygen comments)

^##[^@]
pdb
^ *print *( *" *Dbg
^ *print *( *" *Debug
^ *debug

Answer 2

В случае моих собственных проектов исходный код всегда находится под контролем версий.Перед фиксацией я всегда проверяю графический дифференциал, чтобы увидеть, что изменилось, каким должно быть сообщение о коммите и могу ли я разделиться на более мелкие коммиты.Таким образом, я почти всегда распознаю временный мусор как операторы печати.Если нет, я обычно замечаю это вскоре после этого и могу сделать uncommit, если я еще не нажал (работает для DVCS, как git и bzr, а не с Subversion).

Что касается проблем, которые занимают несколько дней, это простотоже самое.Я не фиксирую, пока проблема не будет решена, а затем снова посмотрю на diff.

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

Answer 3

Ну +1 для начала этого обсуждения. Да, иногда это случается со мной. Я оставил эти pdb и передал код в центральную базу кода, git. Я использую 'Emacs'. Итак, перед фиксацией кода я обычно ищу pdb в файле. Но это беспокойная проверка каждого файла. Итак, перед фиксацией кода я обычно очень тщательно проверяю diff. Я также нахожу лучший способ решить эту проблему.

Answer 4

Я могу дать вам три предложения:

1. Не удалять операторы отладчика. Под этим я подразумеваю оставить их включенными, но сделать их условными в режиме отладки:

# Set this to True to enable Debug code
XYZ_Debug = False

if XYZ_Debug:
    do_debugging()

О, и если код отладки предназначен только для распечатки, вам следует ознакомиться с logging (PyMOTW) . Если вы используете ведение журнала, вы можете:

import logging

# Set this to True to enable debug
XYZ_Debug = False

log = logging.getLogger("XYZ")
log.setLevel(logging.DEBUG if XYZ_Debug else logging.INFO)


log.debug("debug output")

2. Поместите один и тот же уникальный тег (в комментарии) после каждой строки или рядом с каждым блоком:

do_debug_code() # XYZZY

Затем я использую функцию Ebucs Ibuffer, отмечаю все буферы Python и затем ищу вхождения этого тега. Использование некоторой комбинации find / grep / sed, как и в других ответах, также будет работать.

3. Если вы используете Mercurial и знаете Mercurial Queues (или, возможно, захотите узнать их), сохраните код отладки в качестве патча в своей очереди. Когда вы готовы к «производству»; или толчок текущих изменений; вставьте патч, содержащий код отладки, и начните. Вы можете достичь чего-то подобного вне контроля версий с помощью diff и patch.

Answer 5

Я также разрабатываю Python с Vim. Мне никогда не приходилось существенно изменять исходный код для отладки. Я иногда помещаю отладочные операторы печати, и у меня есть привычка ставить «# XXX» после каждого. Потом, когда я захочу удалить их (перед фиксацией), просто поискать XXX и удалить эти строки.

Для исключений я организовал запуск своего кода в буфере Vim с внешним интерпретатором, который настроен на автоматический вход в отладчик при любом необработанном исключении. Затем я автоматически помещаюсь в код в момент возникновения исключения. Я использую модифицированный отладчик, который также может сигнализировать Vim (фактически GTK Gvim), чтобы открыть этот источник в этой строке.

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

попробовать: ... некоторый код Кроме: справиться со всем

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