Ruff preview mode

[CoolCat467]

This pull request enables ruff's preview mode.

Currently a work in progress, but I wanted to see if I've messed anything up in the unit tests.

[jakkdl]

I think I'd vote weakly against using ruff preview.
If you just want to run CI checks it's enough to push to a branch in this repo, without opening a PR. (or even better run tests locally ofc)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.58%. Comparing base (2a66a0d) to head (03d4061).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3024      +/-   ##
==========================================
- Coverage   99.58%   99.58%   -0.01%     
==========================================
  Files         121      121              
  Lines       18166    18164       -2     
  Branches     3275     3273       -2     
==========================================
- Hits        18091    18089       -2     
  Misses         52       52              
  Partials       23       23              

Files with missing lines	Coverage Δ
src/trio/_core/_entry_queue.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_asyncgen.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_instrumentation.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_io.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_mock_clock.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_run.py	100.00% <100.00%> (ø)
src/trio/_dtls.py	97.50% <100.00%> (-0.01%)	⬇️
src/trio/_socket.py	100.00% <ø> (ø)
src/trio/_subprocess.py	100.00% <100.00%> (ø)
src/trio/_tests/test_channel.py	100.00% <100.00%> (ø)
... and 21 more

[CoolCat467]

hash argument fixes being merged in this should fix what caused previous ci runs to fail

[A5rocks]

I was looking at whether ruff catches a forgotten prefix for fstrings like "hello {name}" and found RUF027. It seems to be under preview, so I'm for this change now! (at least for that specific lint, I'm not sure about everything else this has enabled since I haven't looked at the diff recently...)

[TeamSpen210]

Maybe we should enable explicit-preview-rules too. Then only rules we explicitly enable will be used. By definition preview rules might be incorrect, change, etc which would be bad if they suddenly start failing CI. Seems fine to run ruff ourselves when a new release comes out to try these rules though, most of the changes here are fine.

For these preview rules, we probably should disable ANN004 for now, since it produces false positives for all exceptiongroup imports.
RUF029 (async functions without any await etc) should probably be disabled for test code. We don't particularly care about guaranteeing checkpoints there, and often we'll be implementing tasks that just assert/raise, without any async logic. Constantly disabling the rule is just distracting noise.
Similarly ASYNC116, since we're using autojump it doesn't matter if sleeps are excessively long.

[CoolCat467]

There are no AN004s raised in trio when using the most recent version of ruff

[A5rocks]

Can we disable RUF029? We're very deliberate with what is marked async for trio and what isn't so nothing should be missed. Tests are a different story but I don't think it matters for them. The false-positives are annoying! (and very noisy. probably like half of the line changes are adding noqa for this!)

Additionally, I don't think A005 brings any benefit. We know we're shadowing stdlib and that's intentional (well, except the underscore prefixed ones, which nobody cares about shadowing anyways).

[A5rocks]

Left a few comments because some of the changes involved adding trailing commas. IIRC that's a separate PR? I left a comment on every file with the change rather than on every change.

[A5rocks]

Given we're disabling it for all modules it would trigger on, would it make sense to globally ignore it?

[CoolCat467]

I had the intention of disabling it on current triggers so that in the event a new module was added it would be triggered for the new one. To be honest I don't see that realistically happening any time soon, but that was my logic.

[A5rocks]

Ah that would make sense. TBH using the built in setting of names to ignore might work with less noise for that case. I'm not sure what would be better.

[A5rocks]

Everything in my last review seems to be addressed.

I'm not quite sure I like having an explanation with every instance of RUF029 but tbh just seeing that error code doesn't explain much -- I think having different formats of explanations visible at once is getting to me, while it wouldn't while programming (because I would only see a small portion of code).