|
Thanks for the improvement. Ideally we should have a test case for the functionality, even just what you wrote above, but at a minimum I'd say we should expose the availability of StdRegex on the module, say RAPIDJSON_SCHEMA_USES_STDREGEX or something like that, similar to the RAPIDJSON_VERSION attribute. What do you think? |
Sorry, something went wrong.
|
Thanks for the improvement. Ideally we should have a test case for the functionality, even just what you wrote above, but at a minimum I'd say we should expose the availability of StdRegex on the module, say RAPIDJSON_SCHEMA_USES_STDREGEX or something like that, similar to the RAPIDJSON_VERSION attribute. What do you think? You're right it is good to have it exposed on the module, I added it (but I'm not sure if I should add something on typings/rapidjson/init.pyi, let me know if I'm missing something there). I also added an small test case to validate that we can use other regex when the variable is set |
Sorry, something went wrong.
RapidJson uses an in-house regex engine that has limited syntax, we can use std::regex by defining
This patch extends that functionality to python-rapidjson by using the environmental variable RAPIDJSON_SCHEMA_USE_STDREGEX
For example, the following schema uses negative-lookahead (not supported by default engine):
Using this schema leads to a ValidationError using this json {"a": "a", "metadata": 1}:
Expected behavior: