-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[airflow] apply Replacement::AutoImport to AIR302
#17570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
airflow] apply Replacement::AutoImport to AIR312
|
0f5c4c0 to
446ba90
Compare
446ba90 to
95706cb
Compare
|
Hey @ntBre , this is also ready to be reviewed 🙂 btw if we would like to mark AIR3XX as stable, what would be the requirement? are we allow to gradually improve the rules afterward? |
Going by the rule stabilization docs, the main normal requirement is that a rule has been in preview for one minor release cycle. So since these are going into 0.11.x, I think we usually wouldn't consider stabilizing them until 0.13.0, or at least 0.12.0. That page also says:
So we wouldn't want to change them drastically after stabilization, but if you mean something more like adding a few new deprecated imports, I think that would be okay. These rules feel like a bit of an exception to the general guidelines to me, so we could possibly consider stabilizing them sooner, but I'd defer to @MichaReiser or @dhruvmanila on that decision. Were you just hoping that users could access these without enabling preview mode? |
ntBre
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
|
I noticed this a bit late, but is the PR title supposed to say |
You can update it right now as, I think, rooster will fetch the latest PR title :) |
Ahh good to know, I assumed that it took the commit message. Thanks! |
airflow] apply Replacement::AutoImport to AIR312airflow] apply Replacement::AutoImport to AIR302
|
Everything that @ntBre said is what we usually follow. In this case we could possibly stabilize it in the next minor release but that isn't planned in the near future (possibly in June). Do you think there would be any issue in recommending users to use the |
* main: [red-knot] Preliminary `NamedTuple` support (#17738) [red-knot] Add tests for classes that have incompatible `__new__` and `__init__` methods (#17747) Update dependency vite to v6.2.7 (#17746) [red-knot] Update call binding to return all matching overloads (#17618) [`airflow`] apply Replacement::AutoImport to `AIR312` (#17570) [`ruff`] Add fix safety section (`RUF028`) (#17722) [syntax-errors] Detect single starred expression assignment `x = *y` (#17624) py-fuzzer: fix minimization logic when `--only-new-bugs` is passed (#17739) Fix example syntax for pydocstyle ignore_var_parameters option (#17740) [red-knot] Update salsa to prevent panic in custom panic-handler (#17742) [red-knot] Ban direct instantiation of generic protocols as well as non-generic ones (#17741) [red-knot] Lookup of `__new__` (#17733) [red-knot] Check decorator consistency on overloads (#17684) [`flake8-use-pathlib`] Avoid suggesting `Path.iterdir()` for `os.listdir` with file descriptor (`PTH208`) (#17715) [red-knot] Check overloads without an implementation (#17681) Expand Semantic Syntax Coverage (#17725) [red-knot] Check for invalid overload usages (#17609)
Got it. The only concern we have is the |
Summary
This is not yet fixing anything as the names are not changed, but it lays down the foundation for fixing.
Test Plan
the existing test fixture should already cover this change