Airflow upgrade dag schedule argument #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
uranusjr
force-pushed
the
airflow-upgrade-dag-schedule-argument
branch
2 times, most recently
from
c5c2075 to
3803fb8
Compare
|
Not sure why my |
uranusjr
force-pushed
the
airflow-upgrade-dag-schedule-argument
branch
from
3803fb8 to
8a72a7e
Compare
|
| code | total | + violation | - violation | + fix | - fix |
|---|---|---|---|---|---|
| AIR301 | 34 | 34 | 0 | 0 | 0 |
There is an upstream bug with latest version detection jetli/wasm-pack-action#23 This causes random flakes of the wasm build job.
I noticed this was exceedingly slow. Reduces to 3m from 14m
Reduces Linux test CI to 1m 40s (16 core) or 2m 56s (8 core) to from 4m 25s. Times are approximate, as runner performance is pretty variable. In uv, we use the 16 core runners.
Reduces to 3m 50s (extra large) or 6m 5s (large) vs 9m 7s (standard)
…ns (astral-sh#14422) ## Summary closes astral-sh#14279 ### Limitations of the Current Implementation #### Incorrect Error Propagation In the current implementation of lexicographic comparisons, if the result of an Eq operation is Ambiguous, the comparison stops immediately, returning a bool instance. While this may yield correct inferences, it fails to capture unsupported-operation errors that might occur in subsequent comparisons. ```py class A: ... (int_instance(), A()) < (int_instance(), A()) # should error ``` #### Weak Inference in Specific Cases > Example: `(int_instance(), "foo") == (int_instance(), "bar")` > Current result: `bool` > Expected result: `Literal[False]` `Eq` and `NotEq` have unique behavior in lexicographic comparisons compared to other operators. Specifically: - For `Eq`, if any non-equal pair exists within the tuples being compared, we can immediately conclude that the tuples are not equal. - For `NotEq`, if any equal pair exists, we can conclude that the tuples are unequal. ```py a = (str_instance(), int_instance(), "foo") reveal_type(a == a) # revealed: bool reveal_type(a != a) # revealed: bool b = (str_instance(), int_instance(), "bar") reveal_type(a == b) # revealed: bool # should be Literal[False] reveal_type(a != b) # revealed: bool # should be Literal[True] ``` #### Incorrect Support for Non-Boolean Rich Comparisons In CPython, aside from `==` and `!=`, tuple comparisons return a non-boolean result as-is. Tuples do not convert the value into `bool`. Note: If all pairwise `==` comparisons between elements in the tuples return Truthy, the comparison then considers the tuples' lengths. Regardless of the return type of the dunder methods, the final result can still be a boolean. ```py from __future__ import annotations class A: def __eq__(self, o: object) -> str: return "hello" def __ne__(self, o: object) -> bytes: return b"world" def __lt__(self, o: A) -> float: return 3.14 a = (A(), A()) reveal_type(a == a) # revealed: bool reveal_type(a != a) # revealed: bool reveal_type(a < a) # revealed: bool # should be: `float | Literal[False]` ``` ### Key Changes One of the major changes is that comparisons no longer end with a `bool` result when a pairwise `Eq` result is `Ambiguous`. Instead, the function attempts to infer all possible cases and unions the results. This improvement allows for more robust type inference and better error detection. Additionally, as the function is now optimized for tuple comparisons, the name has been changed from the more general `infer_lexicographic_comparison` to `infer_tuple_rich_comparison`. ## Test Plan mdtest included
…-sh#14474) ## Summary Resolves astral-sh#13537. ## Test Plan `cargo nextest run` and `cargo insta test`.
This is one of the slowest remaining jobs in the pull request CI. We could use a larger runner for a trivial speed-up (in exchange for $$), but I don't think this is going to break often enough to merit testing on every pull request commit? It's not a required job, so I don't feel strongly about it, but it feels like a bit of a waste of compute. Originally added in astral-sh#11182
…stral-sh#14476) ## Summary Similar to astral-sh/uv#9244, but we need to use the `mkdocs.generated.yml` file because the `scripts/generate_mkdocs.py` uses the `mkdocs.template.yml` to generate the final config.
It's not actually doing anything per pull request and it's pretty slow? xref astral-sh#14469 It seems useful to build on `main` still to find build regressions? e.g. astral-sh#9368
|
Oh did you add the ecosystem thing? |
…stral-sh#14401) This PR stabilizes the unsafe fix for [zip-instead-of-pairwise (RUF007)](https://docs.astral.sh/ruff/rules/zip-instead-of-pairwise/#zip-instead-of-pairwise-ruf007), which replaces the use of zip with that of itertools.pairwise and has been available under preview since version 0.5.7. There are no open issues regarding RUF007 at the time of this writing.
…le in `printf-string-formatting (UP031)` (astral-sh#14406)
Co-authored-by: Micha Reiser <[email protected]>
…-variable-name (E741)` (astral-sh#14405)
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…ANN102 (astral-sh#14384) Co-authored-by: Micha Reiser <[email protected]>
…PT005 (astral-sh#14385) Co-authored-by: Micha Reiser <[email protected]>
…es (astral-sh#14502) # Summary Closes astral-sh#14455, migrated from astral-sh/docs#106.
…uration for `unconventional-import-alias (ICN001)` (astral-sh#14477) Co-authored-by: Micha Reiser <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
Co-authored-by: Alex Waygood <[email protected]> Co-authored-by: David Salvisberg <[email protected]>
## Summary
Add support for (non-generic) type aliases. The main motivation behind
this was to get rid of panics involving expressions in (generic) type
aliases. But it turned out the best way to fix it was to implement
(partial) support for type aliases.
```py
type IntOrStr = int | str
reveal_type(IntOrStr) # revealed: typing.TypeAliasType
reveal_type(IntOrStr.__name__) # revealed: Literal["IntOrStr"]
x: IntOrStr = 1
reveal_type(x) # revealed: Literal[1]
def f() -> None:
reveal_type(x) # revealed: int | str
```
## Test Plan
- Updated corpus test allow list to reflect that we don't panic anymore.
- Added Markdown-based test for type aliases (`type_alias.md`)
## Summary
This fix addresses panics related to invalid syntax like the following
where a `break` statement is used in a nested definition inside a
loop:
```py
while True:
def b():
x: int
break
```
closes astral-sh#14342
## Test Plan
* New corpus regression tests.
* New unit test to make sure we handle nested while loops correctly.
This test is passing on `main`, but can easily fail if the
`is_inside_loop` state isn't properly saved/restored.
Co-authored-by: Micha Reiser <[email protected]>
…w-re-pattern (RUF039)` (astral-sh#14536) This PR adds a sometimes-available, safe autofix for [unraw-re-pattern (RUF039)](https://docs.astral.sh/ruff/rules/unraw-re-pattern/#unraw-re-pattern-ruf039), which prepends an `r` prefix. It is used only when the string in question has no backslahses (and also does not have a `u` prefix, since that causes a syntax error.) Closes astral-sh#14527 Notes: - Test fixture unchanged, but snapshot changed to include fix messages. - This fix is automatically only available in preview since the rule itself is in preview
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR causes the following rules to ignore stub files, on the grounds that it is not under the author's control to appease these lints: - `PLR0904` https://docs.astral.sh/ruff/rules/too-many-public-methods/ - `PLR0913` https://docs.astral.sh/ruff/rules/too-many-arguments/ - `PLR0917` https://docs.astral.sh/ruff/rules/too-many-positional-arguments/ - `PLW3201` https://docs.astral.sh/ruff/rules/bad-dunder-method-name/ - `SLOT` https://docs.astral.sh/ruff/rules/#flake8-slots-slot - `FBT` https://docs.astral.sh/ruff/rules/#flake8-boolean-trap-fbt (except for FBT003 since that involves a function call.) Progress towards astral-sh#14535
## Summary Resolves astral-sh#14289 The documentation for B028 no_explicit_stacklevel is updated to be more clear. --------- Co-authored-by: dylwil3 <[email protected]>
… annotated function calls properly (astral-sh#14532) ## Summary <!-- What's the purpose of the change? What does it do, and why? --> Fix astral-sh#14525 ## Test Plan <!-- How was it tested? --> New test cases --------- Signed-off-by: harupy <[email protected]>
…sh#14505) ## Summary Resolves astral-sh#12949. ## Test Plan `cargo nextest run` and `cargo insta test`.
…-sh#14520) ## Summary Resolves astral-sh#14519. ## Test Plan `cargo nextest run` and `cargo insta test`.
…ots` as unsafe when there are complex comments in the sequence (`RUF022`, `RUF023`) (astral-sh#14560)
## Summary This is just a small refactor to remove the `FormatFStringPart` as it's only used in the case when the f-string is not implicitly concatenated in which case the only part is going to be `FString`. In implicitly concatenated f-strings, we use `StringLike` instead.
Airflow 3.0 changes the default of the 'schedule' argument. This causes incompatibility if a DAG previously does not specify a schedule explicitly. This is against best practice anyway---you should always prefer to set a schedule explicitly. Due to backward compatibility, Airflow 2 also possesses multiple arguments to set the schedule. These are all being combined into 'schedule' in 3.0. Usages of those old arguments are also detected.
uranusjr
force-pushed
the
airflow-upgrade-dag-schedule-argument
branch
from
fcd7936 to
5607a2f
Compare
|
Submitted upstream as astral-sh#14582 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
POC…