Skip to content

Refactor applicability to use safe and unsafe#7819

Closed
zanieb wants to merge 1 commit intomainfrom
zanie/app-refactor-safe
Closed

Refactor applicability to use safe and unsafe#7819
zanieb wants to merge 1 commit intomainfrom
zanie/app-refactor-safe

Conversation

@zanieb
Copy link
Member

@zanieb zanieb commented Oct 4, 2023

Following much discussion for #4181 at #5119, #5476, #7769, and in Discord, this pull request changes Applicability from using Suggested for uncertain fixes to Unsafe.

Also removes Applicability::Unspecified (replacing #7792).

I have some qualms about how we will explain "manual" fixes to users which are a type of unsafe fix that cannot be applied programmatically. However, since manual fixes are not presented to the user after #7769 we can worry about this in the future.

@zanieb zanieb force-pushed the zanie/app-refactor-safe branch 2 times, most recently from 63d56d6 to b3f5bba Compare October 4, 2023 19:10
@zanieb zanieb added the internal An internal refactor or improvement label Oct 4, 2023
@zanieb
Copy link
Member Author

zanieb commented Oct 4, 2023

Here we structure applicability as two enumerations

  • Automatic
    • Safe
    • Unsafe
  • Manual

We could also consider a flat structure

  • Safe
  • Unsafe
  • Hint / Suggestion / Manual / Display / etc.

or a structure that more closely matches when it is applicable / safe

  • Always
  • Sometimes
  • Never

(implemented in #7821)

@codspeed-hq
Copy link

codspeed-hq bot commented Oct 4, 2023

CodSpeed Performance Report

Merging #7819 will degrade performances by 3.35%

Comparing zanie/app-refactor-safe (c5ae2f1) with main (59c00b5)

Summary

❌ 1 regressions
✅ 24 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark main zanie/app-refactor-safe Change
linter/default-rules[large/dataset.py] 92.6 ms 95.8 ms -3.35%

@github-actions
Copy link
Contributor

github-actions bot commented Oct 4, 2023

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

@zanieb
Copy link
Member Author

zanieb commented Oct 5, 2023

Closing in favor of #7821

zanieb added a commit that referenced this pull request Oct 5, 2023
Following much discussion for #4181 at
#5119,
#5476, #7769,
#7819, and in
[Discord](https://discord.com/channels/1039017663004942429/1082324250112823306/1159144114231709746),
this pull request changes `Applicability` from using `Automatic`,
`Suggested`, and `Manual` to `Always`, `Sometimes`, and `Never`.

Also removes `Applicability::Unspecified` (replacing #7792).
zanieb added a commit that referenced this pull request Oct 7, 2023
After working with the previous change in
#7821 I found the names a bit
unclear and their relationship with the user-facing API muddied. Since
the applicability is exposed to the user directly in our JSON output, I
think it's important that these names align with our configuration
options. I've replaced `Manual` or `Never` with `Display` which captures
our intent for these fixes (only for display). Here, we create room for
future levels, such as `HasPlaceholders`, which wouldn't fit into the
`Always`/`Sometimes`/`Never` levels.

Unlike #7819, this retains the
flat enum structure which is easier to work with.
konstin pushed a commit that referenced this pull request Oct 11, 2023
Following much discussion for #4181 at
#5119,
#5476, #7769,
#7819, and in
[Discord](https://discord.com/channels/1039017663004942429/1082324250112823306/1159144114231709746),
this pull request changes `Applicability` from using `Automatic`,
`Suggested`, and `Manual` to `Always`, `Sometimes`, and `Never`.

Also removes `Applicability::Unspecified` (replacing #7792).
konstin pushed a commit that referenced this pull request Oct 11, 2023
After working with the previous change in
#7821 I found the names a bit
unclear and their relationship with the user-facing API muddied. Since
the applicability is exposed to the user directly in our JSON output, I
think it's important that these names align with our configuration
options. I've replaced `Manual` or `Never` with `Display` which captures
our intent for these fixes (only for display). Here, we create room for
future levels, such as `HasPlaceholders`, which wouldn't fit into the
`Always`/`Sometimes`/`Never` levels.

Unlike #7819, this retains the
flat enum structure which is easier to work with.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

internal An internal refactor or improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant