Comments 25
loggin() но его нужно относительно дольше настраивать
Есть loguru, которую можно вообще не настраивать.
>>> from loguru import *
>>> logger.debug("Hello")
[32m2021-09-19 14:13:48.727[0m | [34m[1mDEBUG [0m | [36m__main__[0m:[36m[0m:[36m1[0m - [34m[1mHello[0m
Информативный вывод.
github.com/Delgan/loguru/issues/246
От статьи ТС легче не стало. Первый же пример:
[Errno 2] No such file or directory
ServerError: Ошибка сервера
Traceback (most recent call last):
File "/Users/user1/Documents/test_debugger.py", line 13, in <module>
Debugger.GlobalManager(typePrint="socket")
File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/console_debugger/logic/debugger.py", line 200, in GlobalManager
raise ServerError(
helpful.date_obj.ServerError: Вероятно сервер не запущен
********************************************************************************
Выполните команду:
python /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/console_debugger/main.py tui
********************************************************************************
В нем настройка, по запуску отслеживания изменений в файлах, занимает значительное время.
Я понимаю плюсы логирования но они не подходят для дебаггинг.
А почему бы не использовать для отладки, гм, отладчик?
В многопоточном и многопроцессорное программирование, точки остановок блокируют интерпретатор, поэтому чтобы хоть как то следить за значениями в перемененных нужно их выводить в какой-то файл, или как в примере, через сокет в интерфейс.
А для этого нужно логирование, потому что вы не успеете увидеть происходящее в интерфейсе.
Для этого я создал простую топорную логику, любой не нужный в данное время обработчик, можно по отдельности включать и отключать. Как вариант для обновления - можно в инициализации указать принудительную задержку для потока, чтобы можно было все разглядеть в реальном времени, но не блокировать полностью поток. Вообще я позиционирую эту программу, изначально для тестирования проекта в процессе его написания, потому много времени уходит на то чтобы разобраться с значениями переменных, а с ней удобно, можно в несколько консолей, в реальном времени следить за состоянием какого-то алгоритма.
from console_debugger import *
Пожалуйста не делайте так. Давайте придерживаться хорошего стиля и импортировать явно то, что нам необходимо.
Есть много проектов, в которых нужно сразу видеть значения переменных в момент выполнения программы. Например, обработка нажатий клавиш пользователем, навигация между страницами в GUI приложениях, обработка данных из форм в веб проектах. В общем, во всех проектах, где есть цикл событий, хорошо бы видеть значения переменных, когда идет процесс отладки. Для этого используют обычный print(), но по стандарту он ограничен одной консолью, или loggin(), но его сложнее настраивать, чем проект console-debugger, так как нужно указывать файл, стиль вывода данных в файл, рейтинг обработки, вручную запускать слежение за файлом, вручную закрывать слежение за файлом, когда вам больше не нужен обработчик. Я понимаю плюсы логирования, но они не подходят для дебаггинга.
Теги тоже проверьте.
Отличная идея.
Можно сделать как надстройку над стандартной logging.
logger = Debuger.SetupLogger(*args)
# и далее как обычно, например так
# а библиотека уже в нужное окно отправит данные в зависимости от уровня логирования
logger.debug('text')
Для этого всего-то надо сделать несколько кастомных Handlers и Formatters внутри вызова SetupLogger.
И не надо никаких "printD(a,'...')"
logging очень гибкая библиотека с помощью Handlers и Formatters можно отправлять что угодно и куда угодно.
Многоконсольный вывод для Python