You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that quickwit-oss/tantivy#2129 has landed, it'd be nice to start thinking about lenient parsing support in the bindings. Obviously, a new version of the crate has to be released but starting to think about this.
I've started working on this, but there are a few points I'd like to iron out how we'd expose the QueryParserError enum. It'd be nice to have types for the errors, but QueryParserError is currently a Rust enum.
An (strawman) idea I had was to have separate classes for each error type. Then, optionally, organize them in a submodule underneath tantivy, i.e. tantivy.query_parser_error or something. Then, the interface could look something like this from the Python side:
Then, the interface could look something like this from the Python side:
Concerning the Union type hint, wouldn't a type hierarchy involving inheritance be pretty idiomatic for Python, e.g. SyntaxError and UnsupportedQuery both inheriting from some QueryParserError base class?
Then, the interface could look something like this from the Python side:
Concerning the Union type hint, wouldn't a type hierarchy involving inheritance be pretty idiomatic for Python, e.g. SyntaxError and UnsupportedQuery both inheriting from some QueryParserError base class?
I posted #114 as a strawman for how this might look.
I played around with using a base class, but there are some challenges with using them with PyO3. I've commented specifically on the PR and in the code about this.
Now that quickwit-oss/tantivy#2129 has landed, it'd be nice to start thinking about lenient parsing support in the bindings. Obviously, a new version of the crate has to be released but starting to think about this.
I've started working on this, but there are a few points I'd like to iron out how we'd expose the
QueryParserError
enum. It'd be nice to have types for the errors, butQueryParserError
is currently a Rust enum.An (strawman) idea I had was to have separate classes for each error type. Then, optionally, organize them in a submodule underneath
tantivy
, i.e.tantivy.query_parser_error
or something. Then, the interface could look something like this from the Python side:cc @adamreichold @cjrh if y'all have thoughts
The text was updated successfully, but these errors were encountered: