Page MenuHomePhabricator

RFC: @dagster_type decorator
Needs ReviewPublic

Authored by max on Aug 17 2020, 1:15 PM.

Details

Summary

This would allow decoratory-style declaration of DagsterType, in line with our other core APIs.

Test Plan

Unit

Diff Detail

Repository
R1 dagster
Branch
dagster-type
Lint
Lint OK
Unit
No Unit Test Coverage

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Aug 17 2020, 1:34 PM
Harbormaster failed remote builds in B16889: Diff 20603!
max requested review of this revision.Aug 17 2020, 2:00 PM
python_modules/dagster/dagster_tests/core_tests/runtime_types_tests/test_dagster_type_decorator.py
53–55

hmm, theres something that feels a little off about this to me. I guess my issue is that the type check function doesn't feel like the center of gravity for what defines a dagster type, at least in my head.

python_modules/dagster/dagster_tests/core_tests/runtime_types_tests/test_dagster_type_decorator.py
53–55

for me a type is a blend of type check, loader, and materializer? i agree that the fundamental object of types feels like, well, the object, not a method.

python_modules/dagster/dagster_tests/core_tests/runtime_types_tests/test_dagster_type_decorator.py
53–55

the description of types in our docs does seem pretty tied to checks: "The Dagster type system helps users describe what kind of values their solids accept and produce. Each solid input and output can be annotated with a DagsterType." https://docs.dagster.io/overview/types

here's a proposal to move loaders and materializers off of types: https://elementl.quip.com/zZjTAP7rts0c/Injectable-loaders-and-materializers

might make the type check more central?

python_modules/dagster/dagster_tests/core_tests/runtime_types_tests/test_dagster_type_decorator.py
53–55

is this more unnatural than @resource ?

python_modules/dagster/dagster_tests/core_tests/runtime_types_tests/test_dagster_type_decorator.py
53–55

Under the current model of types yes -- a resource is fundamentally defined by its resource_creation_fn in a way that a typecheck isn't?