Logger have no isEnabledFor method.

[Valt25]

Hello. Thank you for this library.

Given Logger acts as a ussual logger instance. However default logger have other methods besides debug/info/warning/error/log(etc). One of this is isEnabledFor. And it fails if we pass log_with_context.Logger in logging.LoggerAdapter(or maybe other kind of adapters).

I can fix it. But I would like to know whether it is possible to update the library, there is no releases for nearly 2 years already.

[jamesmishra]

If you submit a PR, I am happy to merge it.

If you want me to write the PR, I can do it within 1-2 weeks when I finish with some other high-priority work.

[Valt25]

Ok, I can prepare the PR, it is not complex. However I have found out that there is no tests set up in this project. So I can not write one for this case

[Valt25]

Hello. I have prepared the PR, can you look at this

[jamesmishra]

Hello @Valt25.

I appreciate your PR, but I realized that the problem might be harder to fix than I previously thought.

The getattr() approach is good, but then it becomes unclear to a type-checker what properties of the Logger are available.

A better solution might be for the Logger class to subclass the base logger, but then I don't know if that would cause any backwards-incompatible changes.

As you have pointed out, I don't have existing tests for this codebase, so I'm hesitant to merge anything that might break something for existing users.

Thanks for submitting the PR. I appreciate the effort, but I might just leave this repo the way it is until I have enough tests to confirm that changes are safe to make.

[Valt25]

The getattr() approach is good, but then it becomes unclear to a type-checker what properties of the Logger are available.

If the issue is connected only with type checkers, we can inherit log_with_context.Logger from logging.Logging

but then I don't know if that would cause any backwards-incompatible changes.

Ok, I see. I think there is no threat to backward compatability. Because before(in current version) log_with_context.Logger just mimic some of logging.Logger methods. However, it is possible, that someone pass log_with_context.Logger instanse as plain logger and somewhere expect attribute error, now they would not get this error, silently.

But that would be new release of package, some changes is expected when using new version of package. If you think that these chages are breaking ones, then it can be 1.0.0(major release) instead 0.7.0(minor release)

@jamesmishra What do you think on it?

[Valt25]

kind reminder here

[Valt25]

One more kind reminder