Great to see this math being made more accessible!
The Python examples seem to have a very strong Java smell. That might just be my prefer for functional styles over OOP styles though.
The Python examples seem to have a very strong Java smell. That might just be my prefer for functional styles over OOP styles though.
We aim to treat Python as a first-class citizen (while keeping it maintainable). For instance, many of the Java methods are mapped to properties on the Python classes with more Pythonic names (see `ScoreExplanation` for an example).
I suspect what gives the Java smell is probably the `SolverFactory`/`SolverConfig`, which is a lot of boilerplate code. A lot of the code can be generated, although we would need to design an API for that.
The fluent (method chaining) API might also be giving the Java smell; I don't see many fluent API being used in Python. In particular, needing to either end lines with `\` or surround the statement with brackets make long fluent chains annoying to use. This is harder to change, since there is no Pythonic alternative that I know of for method chaining.
constraint_factory.create_from_chain(
ForEach(Shift)
| Filter(lambda shift: shift.required_skill not in shift.employee.skills)
| Penalize(HardSoftScore.ONE_HARD)
| AsConstraint("Missing required skill")
)
(
constraint_factory.for_each(Shift)
.filter(lambda shift: shift.required_skill not in shift.employee.skills)
.penalize(HardSoftScore.ONE_HARD)
.as_constraint("Missing required skill")
)
?