Resolve classes and functions relative to script name

[charliermarsh]

Summary

If the user is analyzing a script (i.e., we have no module path), it seems reasonable to use the script name when trying to identify paths to objects defined within the script.

Closes #10960.

Test Plan

Ran:

check --isolated --select=B008 \
    --config 'lint.flake8-bugbear.extend-immutable-calls=["test.A"]' \
    test.py

On:

class A: pass

def f(a=A()):
    pass

[charliermarsh]

I consider changing Module to return &[script_name] in the script case, but the path is typically used for resolving relative imports, and I'm not sure it makes as much sense for us to resolve relative imports relative to the script name given that it's definitionally a standalone script.

[zanieb]

Not worth unit test coverage?

[charliermarsh]

Will try.

[github-actions]

ruff-ecosystem results

Linter (stable)

ℹ️ ecosystem check detected linter changes. (+1 -0 violations, +0 -0 fixes in 1 projects; 43 projects unchanged)

python/typeshed (+1 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --no-preview --select E,F,FA,I,PYI,RUF,UP,W

+ stdlib/typing.pyi:330:10: PYI001 Name of private `TypeVar` must start with `_`

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
PYI001	1	1	0	0	0

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+1 -0 violations, +0 -0 fixes in 1 projects; 43 projects unchanged)

python/typeshed (+1 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview --select E,F,FA,I,PYI,RUF,UP,W

+ stdlib/typing.pyi:330:10: PYI001 Name of private `TypeVar` must start with `_`

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
PYI001	1	1	0	0	0

[charliermarsh]

I think those typeshed changes are arguably good but I'll let @AlexWaygood review.

[AlexWaygood]

I think those typeshed changes are arguably good but I'll let @AlexWaygood review.

The typing.pyi change is definitely correct — we already flag that in flake8-pyi, and I'd expect it to be flagged.

The builtins hit seems like a false positive though — the existing annotation looks correct there. Something now isn't being inferred as being a builtin symbol because we're actually in builtins.pyi itself?

[AlexWaygood]

The builtins hit seems like a false positive though — the existing annotation looks correct there. Something now isn't being inferred as being a builtin symbol because we're actually in builtins.pyi itself?

Oh! I missed that the error was going away rather than being introduced! The typeshed hits both look like clear improvements, then 😃

[codspeed-hq]

CodSpeed Performance Report

Merging #10965 will not alter performance

_{Comparing charlie/script (df60061) with main (06b3e37)}

Summary

✅ 30 untouched benchmarks

[fofoni]

Thank you all for handling this so quickly!!

[charliermarsh]

No problem, sorry that it took a few days to merge -- I had to debug a performance regression 😂