Skip to content

Conversation

@superdosh
Copy link
Contributor

@superdosh superdosh commented Jan 13, 2026

This makes the logic a bit more complex as we don't just clear all existing handlers, but add handlers if they don't already exist.

Also adds some typing so mypy doesn't complain downstream.

@github-actions
Copy link

github-actions bot commented Jan 13, 2026

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

@superdosh superdosh marked this pull request as ready for review January 13, 2026 18:37
@superdosh superdosh requested a review from a team as a code owner January 13, 2026 18:37
@superdosh superdosh requested a review from bkorycki January 13, 2026 18:48
Copy link
Contributor

@wpietri wpietri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the goals of this, but you have added a fair bit more complexity that is not covered by tests.

Are their normal circumstances where handlers already exist but that we want to format them? If so, I'd say add tests explicitly for those circumstances.

If this is just for pytest, though, I'd say it doesn't matter what formatting is in use, and so you can drop some of the complexity.

@superdosh
Copy link
Contributor Author

superdosh commented Jan 13, 2026

Are their normal circumstances where handlers already exist but that we want to format them? If so, I'd say add tests explicitly for those circumstances.

If this is just for pytest, though, I'd say it doesn't matter what formatting is in use, and so you can drop some of the complexity.

@wpietri -- I think most of the added complexity is the part where we check whether the handlers already exist (not the formatting). I think we could leave that out and assume the user won't call configure_logging twice. In that case, we always add a handler, and things simplify quite a bit.

I do think now that we're not clearing all handlers, applying the formatter to all is good since if there's some third party library that adds something, it would be annoying for there to be two different formats showing up in GCP logs.

What do you think?

e: took a crack at the simplified version in the latest commit. Main difference versus prior is getting rid of the clear + the formatting all handlers.

@wpietri
Copy link
Contributor

wpietri commented Jan 13, 2026

@wpietri -- I think most of the added complexity is the part where we check whether the handlers already exist (not the formatting). I think we could leave that out and assume the user won't call configure_logging twice. In that case, we always add a handler, and things simplify quite a bit.

Yeah, I'm fine with assuming that.

I do think now that we're not clearing all handlers, applying the formatter to all is good since if there's some third party library that adds something, it would be annoying for there to be two different formats showing up in GCP logs.

What do you think?

As a general rule I think we should build for known problems rather than speculative problems. I haven't seen this happen, and most libraries respect the existing logging. If it does happen, we can solve it then. But if you have seen it happen, then I'm fine with it as long as you have a test for the use case.

@superdosh superdosh merged commit 57e2028 into main Jan 14, 2026
3 checks passed
@superdosh superdosh deleted the mypy-caplog branch January 14, 2026 02:08
@github-actions github-actions bot locked and limited conversation to collaborators Jan 14, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants