перенаправление sys.stdout к входу Python
Я нигде не вижу смысла «заманивать» кого-либо. Они решают разные проблемы, и вы должны использовать то, что вам подходит.
В Java меньше «Языка» и меньше структур для привлечения новых людей, она независима от платформы и не меняется слишком быстро, позволяя старому коду задерживаться надолго (хорошо для некоторых крупных компаний).
C # имеет тесную интеграцию с рабочим столом и множество приятных функций, которые делают программирование более увлекательным. Он имеет интеграцию .net. У него есть указатели, замыкания и т. Д., Которые усложняют работу с n00bs (допустимая языковая цель, следовательно, базовая), но более интересны для опытных программистов - я не убеждал себя, что эти функции делают вас более продуктивными, но в некоторых ситуациях они могут сделайте ваш код намного приятнее! Также, если вам нужны указатели, вам нужны указатели .
Я не вижу много совпадений в целевой аудитории. Зачем менять язык, чтобы привлекать программистов, если для всей отрасли более полезно иметь два здоровых языка, каждый из которых нацелен на решение разных проблем, привлекая разных разработчиков?
2 ответа
The problem is that the logging module is looking a single layer up the call stack to find who called it, but now your function is an intermediate layer at that point (Though I'd have expected it to report cleanMsg, not __init__, as that's where you're calling into log()). Instead, you need it to go up two levels, or else pass who your caller is into the logged message. You can do this by inspecting up the stack frame yourself and grabbing the calling function, inserting it into the message.
To find your calling frame, you can use the inspect module:
import inspect
f = inspect.currentframe(N)
will look up N frames, and return you the frame pointer. ie your immediate caller is currentframe(1), but you may have to go another frame up if this is the stdout.write method. Когда у вас есть вызывающий фрейм, вы можете получить объект исполняемого кода и посмотреть на файл и имя функции, связанные с ним. например:
code = f.f_code
caller = '%s:%s' % (code.co_filename, code.co_name)
Вам также может потребоваться добавить некоторый код для обработки вызова кода, отличного от Python (например, функций C или встроенных функций), поскольку в них могут отсутствовать объекты f_code.
В качестве альтернативы, после ответа mikej , вы можете использовать тот же подход в пользовательском классе Logger, наследующем от logging.Logger, который переопределяет findCaller для перехода на несколько кадров вверх, а не на один.
Я думаю, проблема в том, что ваши фактические сообщения журнала теперь создаются вызовами logy.error и logy.info в cleanMsg , следовательно, является источником сообщений журнала, и вы видите это как __ init __. py
. Если вы посмотрите в исходный код Python lib / logging / __ init __. py , вы увидите определенный метод называется findCaller , который модуль регистрации использует для определения вызывающего абонента запроса регистрации.
Возможно, вы можете переопределить это в своем объекте ведения журнала, чтобы настроить поведение?