Some parser improvement suggestions: 1. use results names to extract field, operator, and value from Clause - using results names instead of explicit indexing makes pyparsing parsers more robust in the face of future changes2. add missing handler for '!=' operator - this appeared to be a bug by omission3. use `all` and `any` builtins instead of `reduce` with `operator.and_` and `operator.or_` - `all` and `and` will short-circuit, whereas reduce will walk through the entire list of expressions to evaluate them (also, I feel `all` and `any` are more intuitive than `reduce`)4. collapse infix_notation precedence levels from 6 to 3, and minor simplifications to `w` and `operator` expressions - using 2 precedence levels for the same logical operation (such as '&&' and 'and') imparts an artificial precedence of one over the other. In addition, fewer precedence levels will result in faster pyparsing processing at parse time5. use pyparsing PEP8 names (`parse_string` vs legacy `parseString`, etc.) - as of pyparsing 3.0.0, most of the pyparsing API supports PEP8- compliant method and argument names using snake_case. The legacy camelCase names are still supported, but I'll be deprecating and eventually removing them in future releases. Not in this patch, but for additional consideration: add a module-levelcall to pyparsing.ParserElement.enable_packrat() to enable packrat parsing.infix_notation parsers are especially suited to using this optimization. ====================================Developer's Certificate of Origin 1.1By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
_______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
