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 (8850705) to head (ded5cac).
Report is 38 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3024      +/-   ##
==========================================
- Coverage   99.58%   99.58%   -0.01%     
==========================================
  Files         121      121              
  Lines       18157    18155       -2     
  Branches     3272     3270       -2     
==========================================
- Hits        18082    18080       -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

[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).

[CoolCat467]

Going to merge this soon unless anyone has any additional concerns.

[TeamSpen210]

I think it would be good to merge the changes, but perhaps not actually enable preview-mode. By definition these rules are less certain, might have edge cases that don't work, or get reverted. So it'd be bad to update the pin, then suddenly have errors in CI that we might have to revert later. Instead just run them manually when there's a new version, see if we want to do anything at that point.

[A5rocks]

I think it would be good to merge the changes, but perhaps not actually enable preview-mode. By definition these rules are less certain, might have edge cases that don't work, or get reverted. So it'd be bad to update the pin, then suddenly have errors in CI that we might have to revert later. Instead just run them manually when there's a new version, see if we want to do anything at that point.

I think there are a few (like the fstring check rule) that would be nice to have, but maybe that's not worth the churn.

[CoolCat467]

I think it would be good to merge the changes, but perhaps not actually enable preview-mode. By definition these rules are less certain, might have edge cases that don't work, or get reverted. So it'd be bad to update the pin, then suddenly have errors in CI that we might have to revert later. Instead just run them manually when there's a new version, see if we want to do anything at that point.

That is a good point. What if instead, we specifically enabled all of the rules that are preview as of now, and then when new versions come out we can try adding the new ones then? Is it possible to do that with ruff?

[TeamSpen210]

Looks like you can't no. You can specify them, but it won't enable. But we could enable them in preparation.

[CoolCat467]

My current understanding of conversation is that it would be nice if we could specify which preview rules we would like to enable, but that is not possible as of writing. There was discussion about leaving the changes but not enabling preview mode, which I don't think would be a good solution because first if there are noqa lines for preview rule matches, then ruff's unused-noqa will get rid of them, and then we aren't checking future code against preview rules, leading to inconsistency. The idea behind leaving preview disabled is that new preview rules could be introduced which by definition are unstable and might not be good, but my counter is that we could always disable those specific new preview rules, but rightly said is that this will increase difficulty of updating ruff versions, but I don't think it would be too much of a hassle to disable said new rules if required.

Net result, I will continue with earlier stated merging, and in the event this is not the right course of action we can always revert this or apply a better solution on top of this.