added async callable sinks and tests for async callable sinks

[jessekrubin]

Would be super nice to merge this in!

Also in contributing, would be nice if you had a 'format'/'lint' script so it is easier to contribute!

What formatter are you (@Delgan) using?

[Delgan]

Hey @jessekrubin, thanks for the PR. This looks like a good idea!

I noticed that the __call__ attribute is not read-only. Consequently, there is one possible edge case (very contrived example):

def foo():
    pass

async def afoo():
    pass

foo.__call__ = afoo

logger.add(foo)

In such case, the handler is going to end up in a broken state. It expects the sink to return a coroutine object, but calling sink() will execute the synchronous foo() function. I don't expect anyone to ever change __call__ this way, but to prevent that from even being possible, what do you think of wrapping sink.__call__ instead of sink directly?

Also, it's possible that accessing the __call__ results in an AttributeError so I would like to handle that with getattr().

elif inspect.iscoroutinefunction(sink) or inspect.iscoroutinefunction(getattr(sink, "__call__", None)):
    ...

    if inspect.iscoroutinefunction(sink):
        coro = sink
    else:
        coro = sink.__call__

    wrapped_sink = AsyncSink(coro, loop, error_interceptor)

Also I don't think we need to copy/paste the whole test_coroutine_sink.py to test_async_callable_sink.py. It's a bloated enough file that I would prefer not to maintain twice. 😄

Adding a test_async_callable_object() similar to test_coroutine_function() should be enough, as well as the special cases I mentioned.

About formatting: I don't require any particular style for contributors. I run black -l 100 . myself from time to time. You're right, it's not documented. I'll add it to the tox.ini file.

[jessekrubin]

Howdy @Delgan I am down with all of your suggestions (it is your package(!) (and a mighty fine one at that!)).

I get the not wanting to maintain 2 files.

Idk about adding it to tox (I think tox is a whole ordeal), I just was curious what you were doing for formatting as some people are very particular.

[Delgan]

Thanks for the update! Actually, some files under tests/ are not (yet) converted to black style (which broke comparisons between source and formatted exception), sorry you had to revert your commit. 😅

However, I'm still wondering... Why are the entire _logger.py and test_coroutine_sink.y files marked as changed in the PR diff, instead of just the few lines modified: https://github.com/Delgan/loguru/pull/294/files ? 😕

[jessekrubin]

However, I'm still wondering... Why are the entire _logger.py and test_coroutine_sink.y files marked as changed in the PR diff, instead of just the few lines modified: #294 (files) ? 😕

Herm. That is p weird. I do not know! I have an .editorconfig in the dir above where I was working, so maybe it is that? (tho that has never happend to me before so I do not know)

[jessekrubin]

@Delgan I think i figured it out. it a combo of me working on windows, having a .gitattributes and a .editorconfig above where I was working. I can revert and try again.

[Delgan]

Yeah, don't worry, I will make some tests next week-end and we'll figure out something. 👍

[jessekrubin]

@Delgan I ACTUALLY FIGURED IT OUT! If you are curious. (it caused the same thing this afternoon in repo for my work)

I was working in a dir in a repo (where I cloned loguru). The repo above me had core.filemode set to true, so git was tracking the permissions which when changed cause git to think the whole file has changed.

[Delgan]

Thanks @jessekrubin for the investigation! 😄

Indeed, if we look at the raw commit this is mentioned: new file mode 100755.
Github doesn't seem to display this information.

[Delgan]

It was actually a basic problem of line ending. Now it's merged, thanks for the work! :D