Partially override existing stubs with custom stubs (PEP-561)

[bedlamzd]

Hi, this is not an issue but rather a question and sorry for bothering you.

I'm trying to understand is it possible to partially override existing stubs (namely builtin logging module) with custom stubs.
I have code that sets custom logger class for logging module that changes signature of methods (info etc). logging.getLogger by default is annotated to return Logger instance but I want to redefine its signature to return custom class.

I've found that PEP-561 says it should be possible but I had no luck (see the first item in linked paragraph). When I add my custom stubs (with single definition for getLogger) they override builtin module completely. So logging.Logger and everything else now reported as unknown name. This happens both to mypy and pyright.

I've tried adding __getattr__ definition in attempt to signify that stub is partial, but that (obviously) only makes type checker return Any for "missing" names.
Also I tried adding from logging import * to my stub but that has no effect.

Am I misreading the PEP? Am I doing things wrong?

Would appreciate any help

[erictraut]

Converting to discussion.

[erictraut]

You can override stubs at the module level. You cannot override specific symbols within a module.

I've run into a similar case where I wanted getLogger to return a custom logger instance. The approach I took was to write a utility module called custom_logging.py that other modules in my source base could import. The utility module exported a getLogger that returned a custom logger instance, so it was mostly a drop-in replacement for the stdlib version. I simply needed to update the import statements in my code base to point to custom_logging rather than logging. Will that work for you?

The from logging import * won't work if your stub is called logging.pyi because it will simply import from itself.

You could copy the full contents from typeshed's logging.pyi into your own custom typings/logging/__init__.pyi file and modify the individual function, but that would be somewhat fragile because the typeshed version of logging.pyi may change over time.

[bedlamzd]

Okay, thank you for clarifications. Your suggestion was my next idea as well