This message was deleted.

Hey! Hamilton uses them in two ways: (1) validates that the inputs are the right type (2) validates that nodes are matches That said, @Stefan Krawczyk thought about how to make it a looser type-check as an option. https://github.com/stitchfix/hamilton/issues/181. Our hope is its relatively unobtrusive and makes your code more readable, but would be curious why you want to turn it off 🙂

Clarification on (1) — we validate inputs to the DAG (not each function call) match what’s expected when you do

execute()

.

thanks - I think we were debating whether to have functions/nodes return pd.Series vs np.arrays, and realized that we’d have to do a bunch of ‘refactoring’ to make that work due to the type hints (unless from the get-go we declare them as unions). couple of follow ups: 1. if our DAG outputs are now numpy arrays instead of pd.Series, will the driver still produce a pd.Dataframe? if not, will return a dictionary instead (I guess we can always turn it into a df with

from_dict

) 2. if the outputs are a mix of pd.Series and other types (ints, etc.), will the driver automatically fallback to returning dictionaries? i.e. does it concatenate into a df only if everything is a pd.Series, and otherwise returns a dict?

realized that we’d have to do a bunch of ‘refactoring’ to make that work

Search and replace shouldn’t be hard to place in a bunch of unions? Otherwise you can define a graph adapter to make them equivalent. Let me know if you want code for that. Regarding: (1) If using the default driver and adapter then yes — since the following seems to work.

a = {'a': np.array([1,2,3]), 'b': np.array([3, 4, 5])}
pd.DataFrame(a)
   a  b
0  1  3
1  2  4
2  3  5

If you want a dictionary of output then you need to pass in adapter to the driver that will do that. Sorry but I see we’re lacking in docs here — but the idea can be seen in https://hamilton-docs.gitbook.io/docs/reference/api-reference/available-drivers and you change step 3 …