This message was deleted.

Currently it’s a limitation but that’s not necessarily inherent — it should theoretically work. Mind opening up an issue? That said, there really shouldn’t be a need for it — you can probably use the inject as the param name. or you can pass it in each parameterization (which, admittedly, repeats things). One more thing to note — the double underscore has a meaning in hamilton around config (it’s stripped when you have a config.when do you can define multiple in a file) — best practices is to not use it elsewhere but it should work anyway.

Sure wil do. I like the namespace neatness of passing a params dict to each function. I actually prefer

date_range

to live inside params. Is that doable?

Not 100% sure I follow — but I think so. You should just be able to declare the parameter as a dict (or maybe a TypedDict) and pass in any data you in that object… If you want to take multiple upstream sources and group them (e.g. date_range, params), you can use

group(date_range=source(…), params=source(…))

daterange / date_range (same variable - my mistake) appears in the parameterize decorator... I am guessing it needs to be an explicit argument to my_func() for the decorator to work?

Yeah I think you want group. @parameterize/@inject serve as a level of indirection around the parameter — breaks the typical hamilton rule of the parameter has to come from the function with the same name. So yeah, think group is what you want (it has a dict and a list ability)

I keep abusing the intention of your library...I'll show you the final DAG perhaps you will see a better way

Heh happy to take a look. That said, you can only build a tool but you can’t tell people to use it. And if they use it in a slightly different way than intended it sometimes means that you need to rethink what “intended” should mean 😂

😄