You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I ran into a use case today where @sumeetsk was developing an application where he had two different algorithms that needed a different set of parameters for getQuery and processAnswer (some elements common, others not).
To support this, I see three choices:
Enforce that all algs accept arbitrary keyword arguments (through def getQuery(..., **kwargs)). This is the current functionality, and is not preferred (why should an algorithm developer have to modify every other algorithm to get a special argument?)
Modify the wrapper. We can look at the function signature and see what optional arguments the algorithm function can accept and pass in those. This would mean that the app developer would be encouraged to pass in every argument that any algorithm needs (which may be expensive).
Modify myApp.py. We could provide an alg.name to the algorithm developer and they can write an if-statement to see which arguments they want to pass.
Daniel and I discussed this today, and we're not inclined to go with option 2. Our main motive for going with option 3 was that we were doing less and leaving more up to the user -- this provides more flexibility and an explicit explanation of what's going on.
The text was updated successfully, but these errors were encountered:
The issue @sumeetsk is facing has to do with information about the query_uid. In App.py#L150 this is generated after myApp.getQuery for no real reason -- I don't see anything blocking passing the query_uid to myApp.py and editing base.yaml to reflect this.
In general, I still think option 3 is best and I'm sure another use case like Sumeet's will pop up. I still propose adding a name parameter to the alg wrapper we pass to myApp.py.
I ran into a use case today where @sumeetsk was developing an application where he had two different algorithms that needed a different set of parameters for getQuery and processAnswer (some elements common, others not).
To support this, I see three choices:
def getQuery(..., **kwargs)
). This is the current functionality, and is not preferred (why should an algorithm developer have to modify every other algorithm to get a special argument?)alg.name
to the algorithm developer and they can write an if-statement to see which arguments they want to pass.Daniel and I discussed this today, and we're not inclined to go with option 2. Our main motive for going with option 3 was that we were doing less and leaving more up to the user -- this provides more flexibility and an explicit explanation of what's going on.
The text was updated successfully, but these errors were encountered: