Closed Moosems closed 1 month ago
Relates to #5
Flags can be made a secondary issue if this goes forward
I think I like the second option more because it keeps the API much closer to what it was before. Implementation-wise we could internally treat all commands like they are multiple run commands half the time. What I mean by this is we keep a list of commands that allow multiple requests at once, the newest responses dict always corresponds to a list of Response
's, and current ids has all the normal single commands along with ids as mappings. This would look as follows:
self.multi_request_commands: list[str] = []
self.current_ids: dict[str | int, int | str] = {} # str -> int | int -> str
self.newest_responses: dict[str, list[Response] | Response | None] = {}
Ultimately this should try to not break past usages of the API so we have to default to old norms and keep the API similar as much as possible.
Feature report:
Allowing multiple requests of the same command would make the framework much more flexible and I believe this could be done without a major API change. If this is allowed, the user would have to keep track of what id's correspond to what requests for commands allowing multiple requests. They would still run concurrently but perhaps this could be changed to have flags that determine what settings are applied? To modify the simple example, it would likely look similar to this: