Extend pybabel extract's keywords dict format to support multiple keywords with same function name and number of arguments.
Fixes #1067 : pybabel extract command from CLI only respects the first argument passed into keywords
I've been working on a fix for this and I have it working. I've had to extend the keywords dict format to allow for multiple specs per number of arguments, but I've made sure the old format is still accepted (and generated by default, if the extended format isn't required), and all existing unit tests still pass without changes. However I feel my code isn't the most elegant so I would welcome feedback.
The main issue as I see it is that I've used tuples to contain the multiple specs. This creates a situation where we can have several nested tuples and it's difficult to distinguish a tuple for an individual spec from a tuple enclosing (potentially) multiple specs. Would it be more suitable to use a list instead when we need to store multiple specs in the dictionary, or would this introduce too much overhead/potential errors?
Extend pybabel extract's keywords dict format to support multiple keywords with same function name and number of arguments.
Fixes #1067 : pybabel extract command from CLI only respects the first argument passed into keywords
I've been working on a fix for this and I have it working. I've had to extend the keywords dict format to allow for multiple specs per number of arguments, but I've made sure the old format is still accepted (and generated by default, if the extended format isn't required), and all existing unit tests still pass without changes. However I feel my code isn't the most elegant so I would welcome feedback.
The main issue as I see it is that I've used tuples to contain the multiple specs. This creates a situation where we can have several nested tuples and it's difficult to distinguish a tuple for an individual spec from a tuple enclosing (potentially) multiple specs. Would it be more suitable to use a list instead when we need to store multiple specs in the dictionary, or would this introduce too much overhead/potential errors?