Skip to content
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

Splatting keyword arguments #18

Open
GunnarFarneback opened this issue May 29, 2022 · 1 comment
Open

Splatting keyword arguments #18

GunnarFarneback opened this issue May 29, 2022 · 1 comment

Comments

@GunnarFarneback
Copy link

I'm confused by this advice:

When writing a function that sends a lot of keyword arguments to another function, say sending keyword arguments to a differential equation solver, use a named tuple keyword argument instead of splatting the keyword arguments. For example, use diffeq_solver_kwargs = (; abstol=1e-6, reltol=1e-6,) as the API and use solve(prob, alg; diffeq_solver_kwargs...) instead of splatting all keyword arguments.

In my understanding of terminology, ... is the splatting operator and I would say that ; diffeq_solver_kwargs... is splatting the keyword arguments, but as that doesn't make sense here I assume something else is meant by splatting. Could this be clarified?

@ChrisRackauckas
Copy link
Member

I mean "full splats". For example, if you're someone writing a code do_analysis(x,y;my_kwarg = 2, kwargs...), and then you just do sol = solve(prob::LinearProblem,alg,kwargs...); sol = solve(prob::NonlinearProblem,alg,kwargs...) in your package, because SciML has common keyword arguments this thing can work but it can confuse the keyword arguments, or easily pass extra keyword arguments. The better thing to do would be to have in the API some do_analysis(x,y;my_kwarg = 2, linear_solve_kwargs = (;), nonlinear_solve_kwargs = (;)) and then do sol = solve(prob::LinearProblem,alg,linear_solve_kwargs ...); sol = solve(prob::NonlinearProblem,alg,nonlinear_solve_kwargs...) in your package so that you can distinguish between the keyword arguments and make sure kwargs don't overlap. If you just have a bunch of kwargs being splatted around, it can be easy for them to mix, accidentally accumulate kwargs which have undefined or no meaning (with no warnings/errors thrown when someone makes a typo), and ultimately just hidden bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants