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

support regular expression ?? #23

Open
looker53 opened this issue Dec 10, 2020 · 7 comments
Open

support regular expression ?? #23

looker53 opened this issue Dec 10, 2020 · 7 comments

Comments

@looker53
Copy link

e.g.

book.p[content =~ /^pica+$/i]
@simonw
Copy link

simonw commented Mar 19, 2021

I don't think regular expressions should be part of the core JMESPath syntax because different programming languages have different regular expression implementations, so it wouldn't be possible to guarantee that a regular expression run using JMESPath on Python would have the exact same results on PHP or Ruby or Lua or Go.

Instead I suggest writing your own custom function that makes Python regular expressions available to your code: https://github.com/jmespath/jmespath.py/blob/0.10.0/README.rst#custom-functions

@notjames
Copy link

I don't think regular expressions should be part of the core JMESPath syntax because different programming languages have different regular expression implementations, so it wouldn't be possible to guarantee that a regular expression run using JMESPath on Python would have the exact same results on PHP or Ruby or Lua or Go.

Instead I suggest writing your own custom function that makes Python regular expressions available to your code: https://github.com/jmespath/jmespath.py/blob/0.10.0/README.rst#custom-functions

I completely disagree with this assertion. Though many languages do indeed have different implementations, I estimate 99.999% of them use a PCRE library/implementation for regexes as PCRE has become the defacto standard for regular expressions. Moreover, if every language used the rationale to defer to implement regular expressions because other languages do it differently then no language would implement them. I find myself deferring to jq 90% of the time because jp doesn't employ regular expressions.

@mswezey23
Copy link

I'd be in huge support for adding regex support!

@simonw
Copy link

simonw commented Jan 10, 2022

There's a useful comparison table of the differences between different language implementations here: https://web.archive.org/web/20130830063653/http://www.regular-expressions.info:80/refflavors.html

@simonw
Copy link

simonw commented Jan 10, 2022

jq is an interesting comparison here. It actually bundles the full implementation of the regular expression library (a submodule that imports Oniguruma: https://github.com/stedolan/jq/tree/master/modules) that it uses in the C implementation of the tool - then different programming languages have bindings that depend on that shared implementation: https://github.com/stedolan/jq/wiki/FAQ#language-bindings

jmespath works differently: rather than shipping a single C implementation that is shared by different languages, it encourages entirely fresh implementations in different languages with no shared code, but sharing instead a thorough set of compliance tests: https://jmespath.org/libraries.html

Tests are here: https://github.com/jmespath/jmespath.test/tree/master/tests

This approach could be used to add regular expression support, by spinning up a thorough compliance test and maybe defining a subset of regular expression syntax that must be supported in order for an implementation to pass the test.

It would be a lot of work though!

@simonw
Copy link

simonw commented Jan 19, 2022

Here's a really interesting proposal, for an interoperable subset of regular expressions: https://cabo.github.io/iregexp/draft-bormann-jsonpath-iregexp.html

It's still in early stages, but it looks like it's directly relevant to this conversation.

@Harliff
Copy link

Harliff commented Aug 25, 2023

+1 vote for regex support!

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

5 participants