docs: Update docstring for strict flag to make it unambiguous #247
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The previous docstring for the
strict
parameter in theload_toolset
method could be interpreted ambiguously. This change clarifies that whenstrict=True
, an error is raised if any loaded tool instance fails to utilize all of the applicable parameters or auth tokens that were provided globally toload_toolset
.The original phrasing "fails to utilize at least one provided parameter" could have been misconstrued to mean an error only occurs if a tool uses none of the provided parameters. The updated phrasing "fails to utilize all of the given parameters or auth tokens" more accurately reflects the implemented behavior: each tool must exhaustively use all relevant configurations passed to
load_toolset
when in strict mode.Note
Note that neither
strict=False
norstrict=True
mode inload_toolset
will inherently identify a tool within the set that is loaded but does not (and perhaps is not intended to) utilize any of the globally providedauth_token_getters
orbound_params
.For instance, if a user wishes to validate the presence or specific configuration of such a "passively" configured tool (i.e., one that doesn't consume any of the globally provided configurations during the
load_toolset
call), a different approach is needed. In this scenario, the user would need to iterate through the tools individually after they are loaded and use methods likeadd_auth_token_getters()
and/orbind_params()
on a per-tool basis. This allows for checks of compatibility (e.g., whether a specific tool can accept a certain auth token or bound parameter, which would raise aValueError
if it's an unknown or inapplicable configuration for that particular tool) or to confirm expected behavior when such configurations are applied post-loading.Eg.