Don't allow passing in loguru

[crizCraig]

Loguru is not api compatible with standard logging despite efforts in #294, so it may be best to raise an error or wrap the loguru logger with a standard logger when doing this

from loguru import logger
@retry(
    stop=stop_after_attempt(10),
    wait=wait_random_exponential(multiplier=1, max=10),
    reraise=True,
    before_sleep=before_sleep_log(logger, "ERROR"),  # type: ignore
    after=after_log(logger, "ERROR"),  # type: ignore
)

As it can cause a KeyError due to this

Here's a wrapping approach which may be the best thing for people to setup in accordance with their own logging needs. Not sure if @Delgan has a better approach though.

[Delgan]

Hi there.

As per the type-hints in the source code of tenacity, the logger parameter is clearly expecting a standard logging.Logger object:

tenacity/tenacity/before_sleep.py

Lines 31 to 36 in 3100582

	def before_sleep_log(
	logger: "logging.Logger",
	log_level: int,
	exc_info: bool = False,
	) -> typing.Callable[["RetryCallState"], None]:
	"""Before call strategy that logs to some logger the attempt."""

Consequently, users should not expect tenacity to be compatible with Loguru's logger, nor should tenacity developers necessarily care about that. The compatibility error should be raised by static linters such as Mypy.

In this situation, the most appropriate workaround is for users to define a standard logger wrapping Loguru's logger to bridge the gap between the two libraries. I added more details in Delgan/loguru#1008 (comment).

[jd]

Loguru's .log() method expects string level names, not integers — this is a loguru API incompatibility, not something tenacity should work around. The linked loguru issue has a wrapper approach that users can adopt for their specific logging setup.

[Delgan]

Loguru's .log() method expects string level names, not integers

This is incorrect. Loguru does support both integer and level names.

The incompatibility comes from keyword arguments being automatically formatted in the log message by Loguru, whereas exc_info here was not meant for that.

[jd]

Hi @crizCraig and @Delgan I've opened #622 to fix this. The approach is to format the traceback into the message string directly instead of passing exc_info= as a kwarg to logger.log(), which makes it compatible with loguru and any other logger.

Would you mind giving it a review/test?