Embed logger options in returned type

[ThibaultLemaire]

As I originally pointed out in #43 (comment), if we could somehow pass the configured .opt() of a logger in the type we return, we could avoid storing global state.

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.87. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[ThibaultLemaire]

I believe this would also allow fixing cases such as this (excerpt from #42 (comment)):

from loguru import logger

logger.configure(
    handlers=[
        dict(
            sink=sys.stderr,
            format="Site {extra[site]} broadcasting: {message}",
            backtrace=False,
            diagnose=False,
        ),
    ],
    extra={"site": "unknown"},
)

site = 19
scp = 682
# We're passing the `site` number for local formatting of this message,
# but we're also passing the `scp` number as `extra` for the formatter of the handler.
logger.warning("SCP-{} containment breach detected", scp, site=site)
# error: Not all arguments converted during string formatting

[kornicameister]

@ThibaultLemaire If you have an idea how to implement, please do. I am now stucked on various interviews ;).
I see it gets more and more interesting now. We could easily do this similary to lazy=True|False but this will work against your other idea.

If you don't mind, let's rollback to #43 . I can't exactly figure out how an idea from there should work. Do you plan on implementing something inside of loguru or in this plugin? Sorry if that's silly question but it was long ago and I just want to refresh my memory.

[ThibaultLemaire]

If you have an idea how to implement, please do.

Honestly, I'm not sure I do. I just realised while working on #43 that we were returning a Type and that we were free to embed whatever we wanted on that type, so I figured this was the way mypy intended us to keep track of these kind of things (since storing global state is bad apparently). I'd like to dive into that, but I'm sure this is going to be some work, and I don't have the time right-now.

Do you plan on implementing something inside of loguru or in this plugin?

If I'm correct in what I wrote above, I should have all I need in this plugin. I hope I won't have to touch to loguru's source code, but I might consider it if there's no other way, now that mention it.