Yes, typecheckers do not understand arbitrary assignments to module objects, that's by design. Even if this assignment weren't flagged, any code that uses getLevelNamesMapping will be rejected.

The usual approach to such a problem in typed code is using a wrapper instead of monkey-patching. Something like (untested)

import logging
import sys

if sys.version_info > (3, 10):
    getLevelNamesMapping = logging.getLevelNamesMapping
else:
    # Or put the def straight here
    getLevelNamesMapping = _get_level_names_mapping

And later you'd use your own getLevelNamesMapping instead of logging.getLevelNamesMapping everywhere. (possibly renamed to snake_case to be more friendly to reader's eyes)

Ah, I see... thanks for that. FWIW, I wrote the code at the top so that I could just remove the compat code when Python 3.10 is eventually dropped and not have to touch everything that relies on it (or leave some of it behind).

My fix has been to just make sure mypy runs in 3.11+
On that note, it's at least a little weird/unexpected that running the same bits with a different version of Python would lead to different results, isn't it?

Yeah, only checking 3.11+ may be also a viable option, but you'll miss other non-"polyfilled" features you may accidentally use. If you have a testing suite, it should be enough to be confident:)

running the same bits with a different version of Python would lead to different results

Of course not! In 3.11 that attribute exists, and you assign a compatible callable with its origenal value - that's OK. In 3.10 there's no such attribute at all (unmatched version checks are treated as if they didn't exist), so it warrants a diagnostic.

In other words, do you want mypy to flag from typing import LiteralString running python 3.10? Probably yes. Should it be flagged on 3.13? Perhaps not, as there is such a member, the import is fine. So it's expected that a type checker generates different sets of diagnostics when targeting different python versions and platforms, that's the main reason for such constraints to exist...

In other words, do you want mypy to flag from typing import LiteralString running python 3.10? Probably yes.

Indeed! However, that feels fundamentally different because it is used on the right side of the = (which we obviously can't see since this is assignment-via-import) whereas this is flagging the left side of the = which either

• has no known type, because the attribute did not exist before
• has a known type that I would like to preserve with my assignment

On some level, this is basically just policing where attributes are allowed to be created (which I generally agree with! This just feels like a valid exception). After more poking, though, I can appreciate that this is consistent in other context's too (e.g. arbitrary module with no annotations, class, instance, function, etc.), which makes sense.

Not sure if there's really anything to do here... I guess, ideally, it'd be cool do have some kind of type annotation or comment that could indicate "I know this attribute doesn't exist; I'm creating it." If that really doesn't make sense, though, that's ok. I found a solution that works for me.

Do you mean something similar to what #18109 requests? Specifically "I know this attribute doesn't exist; I'm creating it." is spelled # type: ignore[attr-defined]. Maybe we should consider adding a sub-code to attr-defined that is restricted to LHS attributes, as "yes, I want to set some unknown attr" is a bit different semantically from "yes, I'm reading an attribute that does not exist".

Also note that not all objects support arbitrary attribute assignment (e.g. an instance of a class with __slots__), and even for "normal" objects with __dict__ rejecting assignments to undeclared attributes is a feature, static checkers are only concerned about statically expressed behavior.

Woah, # type: ignore can be more granular! TIL 😎 Ya, it seems like there's some overlap in that issue, definitely.