Support choices with differing required values in a ConditionSet.

Review Request #8349 — Created Aug. 25, 2016 and submitted

Information

Djblets
release-0.10.x
364629b...

Reviewers

Previously, a ConditionSet's list of choices all had to accept the same
exact type of value for matches. Callers couldn't mix-and-match
different types of condition choices. If there were two pieces of data
to work with (say, a book and an author), the list of choices all had to
accept one of those, and infer the other (if possible).

Now, ConditionSet.matches() takes keyword arguments for the values,
instead of a single positional argument for a single value. These are
compared to BaseConditionChoice.value_kwarg for each condition being
matched.

By default, choices expect a value= keyword argument. More advanced
usage might have some choices that take book= and others that take
author=, as per the example above.

Unit tests pass.

Description From Last Updated

This whole thing could be reduced to: results = list(results) return results and all(results)

daviddavid
reviewbot
  1. Tool: Pyflakes
    Processed Files:
        djblets/conditions/conditions.py
        djblets/conditions/choices.py
        djblets/conditions/tests/test_conditions.py
    
    
    
    Tool: PEP8 Style Checker
    Processed Files:
        djblets/conditions/conditions.py
        djblets/conditions/choices.py
        djblets/conditions/tests/test_conditions.py
    
    
  2. 
      
david
  1. 
      
  2. djblets/conditions/conditions.py (Diff revision 1)
     
     
     
     
     
     
     
     
     
     

    This whole thing could be reduced to:

    results = list(results)
    return results and all(results)
    
    1. It could, but I'm intentionally avoiding computing all of them up-front.

      Condition sets are not always going to match, which is basically the point. A condition set might be designed to notify a particular Slack channel based on repository and diff file path. Processing these lazily, using the generator, means that if one condition (say, the repository match) fails early, we don't have to process other potentially expensive conditions (like computing diff paths, or something else).

      If we fetch it all up-front, we process them all, likely unnecessarily.

      That's why it's doing a more unrolled version of that check. So we can check the bare minimum but still compute whether we processed any results.

  3. 
      
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-0.10.x (6368403)
Loading...