Bye bye 

PythonObjectDagsterType

 and bye bye (mostly) to 

make_python_type_usable_as_dagster_type

  I wanted to highlight a recent change that makes Dagster easier to use with PEP 484 type annotations. Previously, 

@solid

-decorated functions would only accept type annotations for a limited subset of types.  E.g. the following code would fail with a `DagsterInvalidDefinitionError`:

class MyClass:
    pass

@solid
def my_solid(_, input1: MyClass):
   pass

As of 0.11.0, this is a valid definition. Dagster will automatically construct a 

DagsterType

 for 

MyClass

, which means it will automatically show up in Dagit as well. This change should significantly reduce boilerplate in some situations.  You should never need to instantiate a 

PythonObjectDagsterType

, and you should only need to use the 

usable_as_dagster_type

 and 

make_python_type_usable_as_dagster_type

 APIs in situations where you want to apply a custom type check function to every instance of a particular Python type. Happy typing!

cc: @dwall i think this will be of interest

Woo!!

that's nice! i'm inspecting the dagster type in my IO Manager, is there a way to reconstruct what dagster does with the class?

i believe the

python_type

property should be consistent between the old way and this new way - calling that on the

DagsterType

might be the way to go. @sandy can confirm

@Alessandro Marrella - in your

load_input

, you can access

context.dagster_type.python_type

. Does that answer your question?

i believe it does, thanks! 🙇

Praise be