Elijah ben Izzy

OK, so I have some code that you can play around with if you want! It has both implementations (dataframes uses the other). See PR #227. To install, you can:...

> Just tried out `@parameterize_extract` and `@parameterize_frame` on my main use case, they both work great. I was confused by `@parameterize_frame` as currently written because it required the output columns...

Closed in favor of #238

I like my (somewhat hacky) approach more -- what you suggested above. This is easy, can be copy/pasted anywhere, and doesn't require a framework change: ```python class mock_modifier: def __getattr__(self,...

> > I like my (somewhat hacky) approach more -- what you suggested above. This is easy, can be copy/pasted anywhere, and doesn't require a framework change: > > ```python...

Chiming in -- so yes, this does make inherent sense. We could expose `HamiltonNode` to be the node it decorates, we'd just have to make it backwards compatible. Could be...

Hmm, config nodes shouldn't be in `list_available_variables`... The fact that they show up is a bit of a hack, no?

> Looking at git blame and going off memory, `.list_available_variables()` used the `Variable` construct. Now, the `driver` module defines `Variable = graph_types.HamiltonNode` to standardize the API and deprecate `Variable`. One...

> Config becomes nodes in the graph -- and you have always been able to request config/inputs as outputs. So not weird to me. They should have the appropriate metadata...

> config is a place to put invariant inputs as well; i.e. "config", the dictionary passed in for it, can be a runtime input. It's always been that way. Yes,...