Abstract syntax tree parser for ConfigSpace

[thijssnelleman]

Adding in logic for parsing expressions into ConfigSpace Conditions/Forbiddens. This is aimed to take general logic expressions (strings) and uses the AST library to convert it into a ConfigSpace expression.

The reason of this being necessary is as a build up towards enabling parsing a ConfigSpace from other notation files, such as PCS files from SMAC2, IRACE etc.

[thijssnelleman]

TODO: Add more docs into the methods, s.t. we have examples for the documentation site

[thijssnelleman]

@mfeurer

Added new docs example for usage, cleaned up code and other comments. I think its ready for a review now.

[thijssnelleman]

@mfeurer Reminder for this PR

[Copilot]

Pull request overview

Adds an AST-based parser that converts string logic expressions into ConfigSpace Condition or ForbiddenClause objects, to support importing ConfigSpaces from external notations (e.g., PCS/SMAC/IRACE).

Changes:

• Introduces expression_to_configspace() (and a recursive AST conversion helper) to map comparisons and boolean logic into ConfigSpace Conditions/Forbiddens.
• Adds unit tests covering basic parsing cases (value comparisons, HP relations, conjunctions/disjunctions, in).
• Extends imports to include additional Forbidden clause/conjunction types used in the new tests.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
src/ConfigSpace/util.py	Adds AST parsing and recursive conversion into ConfigSpace Condition/Forbidden objects.
test/test_util.py	Adds tests for expression_to_configspace() covering simple/complex expressions and error cases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[karibbov]

Hi, I'm finally able to wrap my head around what expression_to_configspace does. Thanks for your patience 😅

TL;DR: expression_to_configspace works as expected and parses ast expressions to be either Forbidden expressions or Condiditional statements depending on if the target_hyperparameters argument is passed into it. It's compexity is necessary, but I think we can wrap it into two different functions to keep the api clean and easy to understand.

Summary

expression_to_configspace does two different things:

1. When the target_hyperparameter argument is not provided, it'll parse the expression as forbidden. This means the (ast) expression will never resolve to true across the samples from the configspace.
2. When the target_hyperparameter argument is provided, it'll parse the expression as a conditional expression, where the target_hyperparameter will be conditional hyperparameters. In this case the expression (if expression -> conditional_hyperparameter) will always be true. The final result is essentially the inverse of the first case, which makes the function api confusing without diving deep into the implementation details of ConfigSpace. Furthermore, some expressions, such as HP relations and non-strict inequalities are not supported for conditional HPs but are for Forbiddens.

Suggestions

1. We can instead offer 2 wrapper functions: forbidden_expression_from_ast and conditional_expression_from_ast, where the former does not expose the target_hyperparameter argument while the second one requires it.
2. This would also make the testing cleaner, as we can test both functionalities separately and add complex expression tests for conditional HPs as well.
3. I would also suggest considering to refactor expression_to_configspace -> expression_from_ast (to further prevent confusion if this function would actually add the expression to the configspace or not) and target_hyperparameter -> conditional_hyperparameter (more explicit).

[thijssnelleman]

Hi, I'm finally able to wrap my head around what expression_to_configspace does. Thanks for your patience 😅

TL;DR: expression_to_configspace works as expected and parses ast expressions to be either Forbidden expressions or Condiditional statements depending on if the target_hyperparameters argument is passed into it. It's compexity is necessary, but I think we can wrap it into two different functions to keep the api clean and easy to understand.

Summary

expression_to_configspace does two different things:

1. When the target_hyperparameter argument is not provided, it'll parse the expression as forbidden. This means the (ast) expression will never resolve to true across the samples from the configspace.
2. When the target_hyperparameter argument is provided, it'll parse the expression as a conditional expression, where the target_hyperparameter will be conditional hyperparameters. In this case the expression (if expression -> conditional_hyperparameter) will always be true. The final result is essentially the inverse of the first case, which makes the function api confusing without diving deep into the implementation details of ConfigSpace. Furthermore, some expressions, such as HP relations and non-strict inequalities are not supported for conditional HPs

Suggestions

1. We can instead offer 2 wrapper functions: forbidden_expression_from_ast and conditional_expression_from_ast, where the former does not expose the target_hyperparameter argument while the second one requires it.
2. This would also make the testing cleaner, as we can test both functionalities separately and add complex expression tests for conditional HPs as well.
3. I would also suggest considering to refactor expression_to_configspace -> expression_from_ast (to further prevent confusion if this function would actually add the expression to the configspace or not) and target_hyperparameter -> conditional_hyperparameter (more explicit).

1. Agreed with point three, renaming is much more clear to the user for the parameter (Although @mfeurer may argue that it should be named child_hyperparameter to be consistent with other code?). I have updated the code accordingly.
2. However I disagree with the function rename as we are not converting from ast, but from strings. Perhaps a slightly different name may be more clear? expression_from_string?
3. I also do not think we should offer two entry points wrapping the underlying function, unless there is a clear user demand for it. The current workflow is documented so it's relatively easy for users to understand it. Although it would be a very clear separation indeed.

[karibbov]

Fair points! I don't have strong opinions about the user base or the naming conventions yet 😄. We can merge if @mfeurer also doesn't have strong opinions against it.