Timefold Solver is an AI constraint solver for Python to optimize the Vehicle Routing Problem, Employee Rostering, Maintenance Scheduling, Task Assignment, School Timetabling, Cloud Optimization, Conference Scheduling, Job Shop Scheduling, Bin Packing and many more planning problems.
In general, ai.timefold.solver.core.api.x and its subpackages -> timefold.solver.x.
Exception for ai.timefold.solver.core.api.solver, which it and its subpackages -> timefold.solver.
ai.timefold.solver.core.x and its subpackages -> timefold.solver.x (test and config).
Use dynamic all when not TYPE_CHECKING for score and domain, since they have some classes that require the JVM to be started When TYPE_CHECKING, there are stub classes that the TYPE_CHECKER will see.
Remove @incremental_score_calculator decorator, since it been replaced by IncrementalScoreCalculator ABC.
Create an empty Constraint stub so users can reference it in their type signatures without importing something from Java.
Where should nearby_distance_meter go (which is inside an impl.heuristic.selector)? I currently have it with the domain classes; probably should be moved to timefold.solver.heuristic?
In general, ai.timefold.solver.core.api.x and its subpackages -> timefold.solver.x.
Exception for ai.timefold.solver.core.api.solver, which it and its subpackages -> timefold.solver.
ai.timefold.solver.core.x and its subpackages -> timefold.solver.x (test and config).
Use dynamic all when not TYPE_CHECKING for score and domain, since they have some classes that require the JVM to be started When TYPE_CHECKING, there are stub classes that the TYPE_CHECKER will see.
Remove
@incremental_score_calculator
decorator, since it been replaced byIncrementalScoreCalculator
ABC.Create an empty Constraint stub so users can reference it in their type signatures without importing something from Java.