-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconcile internal use of misc.as_list() with API argument types. #311
Comments
From @andre-merzky:
There are several cases in raptor where it seems appropriate to allow tuples or generators to be passed instead of lists, but I do not believe these are in high frequency code paths. If If the type casting is necessary (are tuples and generators really not okay?), then doing it on the application side is fine, but the application programmer needs to be directed to do so more clearly. |
I certainly agree on the sentiment. The API needs better and more stringent type documentation, and we can indeed reconsider the types we accept in the API. Happy to leave the issue open in that context. |
It also seems that, if |
The calling happens in basically the same context every time, and we are confident that the current semantics is what the caller would do anyway. |
as_list()
is frequently used to normalize inputs for RCT commands that accept singular arguments for parameters that are generically multi-valued. However, it does not recognize non-list sequences, such as tuples or generators. This imposes unnecessary constraints and even possibly performance bottlenecks (such as when filtering requests in theraptor.Master.request_cb
) or may cause unexpected behavior (if a user passes atuple
orset
of states torp.wait()
).The obvious exceptions to iterables that should be allowed are
str
andbytes
. There are RCT objects that may be acceptable individually or in groups, but I believe they all satisfyisinstance(obj, collections.abc.Mapping)
. If not, maybe there is a root RCT object they are descended from?In addition to (or instead of) updating
misc.as_list()
, anas_iterable()
oras_rct_arg()
utility function might be added and used judiciously in many of the currentas_list()
call sites.Another alternative would be to add richer checking or casting based on an optional argument asserting the expected type of the list element, but that might be hard to read or surprising for RCT developers, and it would be hard to decide whether to try to convert arguments or elements or to just reject them.
The text was updated successfully, but these errors were encountered: