Skip to content
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

Merged
merged 18 commits into from Jul 8, 2022
Merged

Assorted type annotations #8356

merged 18 commits into from Jul 8, 2022

Conversation

smackesey
Copy link
Collaborator

@smackesey smackesey commented Jun 13, 2022

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:

  • Added declarations of instance attributes to several classes. In some cases corresponding type declarations at the point of assignment of instance variables were removed.
  • Many type annotations using Dict/List/Set replaced with Mapping/Sequence/AbstractSet respectively. Sometimes
    corresponding runtime type checks were also swapped (e.g. check.list_param > check.sequence_param)
  • Added many missing argument and return type annotations
  • Factored out a few complex Callable or Union types into more readable type aliases
  • Fixed various incorrect annotations
  • Added some type-ignores where added annotations triggered mypy bugs

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:

  • dagster.config.traversal_context: config schema args should be non-optional
  • dagster.core.definitions.configurable: use isinstance (legible to type-checkers) instead of custom method that calls
    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.

@vercel
Copy link

vercel bot commented Jun 13, 2022

The latest updates on your projects. Learn more about Vercel for Git ↗︎

3 Ignored Deployments
Name Status Preview Updated
dagit-storybook ⬜️ Ignored (Inspect) Jul 8, 2022 at 8:24PM (UTC)
dagster ⬜️ Ignored (Inspect) Jul 8, 2022 at 8:24PM (UTC)
dagster-oss-cloud-consolidated ⬜️ Ignored (Inspect) Jul 8, 2022 at 8:24PM (UTC)

@smackesey
Copy link
Collaborator Author

smackesey commented Jun 13, 2022

Current dependencies on/for this PR:

This comment was auto-generated by Graphite.

@smackesey smackesey force-pushed the sean/type-annotations branch 2 times, most recently from 08db1ba to 951bcab Compare June 13, 2022 20:49
Base automatically changed from sean/io-manager-types to master June 14, 2022 01:12
@smackesey smackesey force-pushed the sean/type-annotations branch 2 times, most recently from 021bb43 to ce5eed9 Compare June 20, 2022 19:12
@smackesey smackesey force-pushed the sean/type-annotations branch 2 times, most recently from fc851e3 to 42d50ba Compare July 1, 2022 14:32
@smackesey smackesey mentioned this pull request Jul 4, 2022
@smackesey smackesey force-pushed the sean/type-annotations branch 2 times, most recently from 7701e08 to ddf970b Compare July 5, 2022 13:20
@smackesey smackesey requested review from dpeng817 and sryza July 5, 2022 16:21
@sryza
Copy link
Contributor

sryza commented Jul 5, 2022

Is this meant to be marked as a draft?

@smackesey smackesey marked this pull request as ready for review July 5, 2022 18:22
@smackesey
Copy link
Collaborator Author

smackesey commented Jul 5, 2022

Is this meant to be marked as a draft?

Whoops forgot to unmark it

Comment on lines 56 to 72
_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]

Copy link
Member

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?

Comment on lines +401 to +409
_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]
Copy link
Member

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

Copy link
Collaborator Author

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

Comment on lines 18 to 21
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)
Copy link
Member

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

Copy link
Collaborator Author

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

@smackesey smackesey merged commit 2d35b84 into master Jul 8, 2022
@smackesey smackesey deleted the sean/type-annotations branch July 8, 2022 21:30
Jiafi pushed a commit to Jiafi/dagster that referenced this pull request Jul 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants