Support forcing a selector type into a subselector #299
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # parsel/selector.py # tests/test_selector.py
|
Great! This approach is also viable, but users might still adhere to their old habits of not adding a type parameter. In such cases, operations on text type nodes could still lead to some hard-to-trace issues. Should we consider making the Selector's type strongly typed, requiring a conversion to a usable type before performing queries, to avoid implicit type conversions? |
Sounds interesting, could you elaborate? What user-facing API do you have in mind, how would it compare to passing the parameter? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Alternative to #298.
I’m not sure which one is the better approach, though.
But supporting this feature was part of one of the original iterations of JMESPath support, and it was removed at some point because we saw no use for it; it feels like this is a use case to justify its addition.
Fixes #297, resolves #298.