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
Assorted type annotations #8356
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
08db1ba
to
951bcab
Compare
bd60c90
to
653a40a
Compare
951bcab
to
d109928
Compare
021bb43
to
ce5eed9
Compare
fc851e3
to
42d50ba
Compare
7701e08
to
ddf970b
Compare
Is this meant to be marked as a draft? |
Whoops forgot to unmark it |
_node_def: NodeDefinition | ||
_keys_by_input_name: Mapping[str, AssetKey] | ||
_keys_by_output_name: Mapping[str, AssetKey] | ||
_partitions_def: Optional[PartitionsDefinition] | ||
_partition_mappings: Mapping[AssetKey, PartitionMapping] | ||
_asset_deps: Mapping[AssetKey, AbstractSet[AssetKey]] | ||
_resource_defs: Mapping[str, ResourceDefinition] | ||
_group_names_by_key: Mapping[AssetKey, str] | ||
_selected_asset_keys: AbstractSet[AssetKey] | ||
_can_subset: bool | ||
_metadata_by_asset_key: Mapping[AssetKey, MetadataUserInput] | ||
|
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.
seeing this sent me on a journey trying to better understand class attributes vs instance attributes - I'm surprised the types didnt propagate from __init__
correctly though, i guess issues witch check
calls?
_asset_keys_by_node_input_handle: Mapping[NodeInputHandle, AssetKey] | ||
_asset_info_by_node_output_handle: Mapping[NodeOutputHandle, AssetOutputInfo] | ||
_asset_deps: Mapping[AssetKey, AbstractSet[AssetKey]] | ||
_dependency_node_handles_by_asset_key: Mapping[AssetKey, Set[NodeHandle]] | ||
_source_assets_by_key: Mapping[AssetKey, "SourceAsset"] | ||
_asset_defs_by_key: Mapping[AssetKey, "AssetsDefinition"] | ||
_asset_defs_by_node_handle: Mapping[NodeHandle, Set["AssetsDefinition"]] | ||
_io_manager_keys_by_asset_key: Mapping[AssetKey, str] |
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.
alright seeing this repeated im definitely curious to hear about why you took this approach
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.
A few reasons:
- This is the standard way to annotate instance attrs in Python-- see PEP 526. There is a special
ClassVar
annotation you use for class variables. - IMO it is a lot more readable than annotations in `init.
I'm surprised the types didnt propagate from init correctly though, i guess issues witch check calls?
- Yes, the types are often not inferred correctly in
__init__
. I think it would work the same as the above style if we explicitly annotated the type for every assignment in__init__
, but I'm not 100% sure. Regardless, it's a lot harder to read/find the declared type when its embedded in often lengthy__init__
logic. - The above style matches the style used by dataclasses and pydantic, which I still hope to transition to
def test_schedule_context_backcompat(): | ||
# If an instance of ScheduleEvaluationContext is a ScheduleExecutionContext, then annotating as | ||
# ScheduleExecutionContext and passing in a ScheduleEvaluationContext should pass mypy | ||
assert isinstance(ScheduleEvaluationContext(None, None), ScheduleExecutionContext) |
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.
it would be surprising to accidentally delete since theres a comment next to it - but you could preserve a test here that just annotates some functions as am additional guard
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.
I actually realize now that I made a mistake in making ScheduleExecutionContext
a type alias, because it's a literal alias of ScheduleEvaluationContext
that's exported top-level. I guess we'll remove with 1.0 but for now I'll restore it (and the test), though the comment I think is wrong, we're not testing if mypy passes here but rather python isinstance
ddf970b
to
d739da8
Compare
d739da8
to
efc4198
Compare
Summary & Motivation
This is a large PR with a lot of type annotation improvements and a few other minor changes. Unfortunately it is difficult to break up into anything smaller because typing changes cause cascading mypy errors-- adding annotations in one place causes errors to surface in another place, which then needs type annotations added, etc. However review shouldn't be too difficult since most of the changes are pretty trivial:
corresponding runtime type checks were also swapped (e.g.
check.list_param
>check.sequence_param
)In several other places
check.not_none
was inserted where there was an implicit assumption that a value was non-null, but this wasn't inferrable by the type-checker.There are also a few minor runtime changes:
isinstance
Finally, internal requires updates to match these, here's the sister PR: https://github.com/dagster-io/internal/pull/2498. That should be merged after this, which will need to be merged with the internal compatibility check still red.
How I Tested These Changes
Existing test suite.