Uh, I realized my workaround is wrong; using a `# type: ignore` only suppresses the error on that line, and mypy, not getting a type hint as in `# type: Logger`, moves on with the assumption that `logger` is `logging.Logger`, and declares any custom method as nonexistent:
```py
import logging
class Logger(logging.Logger):
def foo(self):
pass
logging.setLoggerClass(Logger)
logger = logging.getLogger(__name__) # type: ignore
logger.foo()
```
```console
$ mypy test.py
test.py:9: error: "Logger" has no attribute "foo"
```
So I learned a new workaround — casting:
```py
import logging
from typing import cast
class Logger(logging.Logger):
def foo(self):
pass
logging.setLoggerClass(Logger)
logger = cast(Logger, logging.getLogger(__name__))
logger.foo()
```
```console
$ mypy test.py # this time happy
```
This feels rather intrusive, but I can settle with this if there's no satisfactory fix.
logging.getLogger() infers wrong type when used in combination with logging.setLoggerClass()
============================================================================================
Consider `test.py`:
```py
import logging
class Logger(logging.Logger):
pass
logging.setLoggerClass(Logger)
logger = logging.getLogger(__name__) # type: Logger
```
```console
$ mypy test.py
test.py:7: error: Incompatible types in assignment (expression has type "logging.Logger", variable has type "test.Logger")
```
The problem here is that `logging.getLogger()` actually returns a logger of the class set previously by `logging.setLoggerClass()`, but the stub is inflexible and just assumes `logging.Logger`.
I'm not sure how to fix this, or whether it's fixable with mypy's current feature set. I'd be happy to take this on if someone could point me in the right direction.
In the meantime, is there a better workaround than just `# type: ignore` the line?