Unexpected side-effect to calling LoggerFactory()

[hp685]

I'm using structlog package 19.2.0 but I've validated the behavior to be the same in version 19.1.0.
Instantiating LoggerFactory causes all subsequent calls to logging.getLogger to be of type
structlog.stdlib._FixedFindCallerLogger.

import logging
from structlog.stdlib import BoundLogger, LoggerFactory
from structlog import wrap_logger

print (logging.getLogger('foo'))
print(wrap_logger(logging.getLogger('bar'), 
	logger_factory=LoggerFactory(), wrapper_class=BoundLogger))

print(logging.getLogger('jazz'))  # would expect this to be a logging.Logger instance

prints

logging.Logger object at 0x10169bf90>
<BoundLoggerLazyProxy(logger=<logging.Logger object at 0x101732990>, wrapper_class=<class 'structlog.stdlib.BoundLogger'>, processors=None, context_class=None, initial_values={'logger_factory': <structlog.stdlib.LoggerFactory object at 0x1017dbad0>}, logger_factory_args=())>
<structlog.stdlib._FixedFindCallerLogger object at 0x1017db8d0>

A minimal example (May not be appropriate usage. Only to illustrate)

import logging
from structlog.stdlib import LoggerFactory

print(logging.getLogger('foo'))
LoggerFactory()
print(logging.getLogger('jazz'))  # would expect this to be a logging.Logger instance

prints

<logging.Logger object at 0x1085b9f90>
<structlog.stdlib._FixedFindCallerLogger object at 0x108650990>

This is a rather unexpected side-effect and causes client's code to return an unexpected type for logging.getLogger calls if structlog LoggerFactory is ever instantiated in a parent application. Is this something that can be addressed?

[hynek]

Why ist that a problem to you? The class that replaces it is a subclass of Logger and should be fully compatible. The behavior is also documented:

Sets a custom logger using logging.setLoggerClass() so variables in log format are expanded properly.

[hp685]

Hey @hynek,

It causes class name change for downstream applications' logger that run within a host app, which can be perplexing for maintainers of downstream apps.

In my scnenario, the application supports dynamic updates and based on some config value, we set the logger type to logging.Logger, structlog or a custom logger. Each logger also logs the class name and it's difficult to differentiate if every logger returns structlog.stdlib._FixedFindCallerLogger after structlog is used at least once.