TimefoldAI / timefold-solver-python

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.
https://timefold.ai
Apache License 2.0
27 stars 3 forks source link

fix: Use Python object for Score, handle descriptor correctly, do not copy parent fields #66

Closed Christopher-Chianelli closed 3 weeks ago

Christopher-Chianelli commented 1 month ago
sonarcloud[bot] commented 1 month ago

Quality Gate Passed Quality Gate passed

Issues
48 New issues
0 Accepted issues

Measures
0 Security Hotspots
80.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

zepfred commented 1 month ago
Using Python object for Score allows Python libraries to interpret the
score, allowing the @planning_solution class, justification and
other Python classes that has a score to be used by Pydantic and
the like. This also allows Score | None to be used in type
annotations.

There are some nice Java tests validating the conversion between Python and Java objects. However, I couldn't find any Python code using or testing the new score structure. I recommend adding some domain/tests using medium and bendable scores.

Previously, parent fields were sometimes added to the instance
field candidate set, causing some fields to incorrectly be None
when unwrapping a PythonLikeObject. Now, all parent fields are
removed from the instance field candidate set.

There are some new tests, but I'm not entirely sure they cover all the behavior added by this change. Am I wrong?

Made toString() call $method$__str__(), and change the return
type of $method$__str__() to PythonString so overrides work
correctly.

I noticed that you didn't update all Python types, such as 'PythonLikeList'. Is there any specific reason for that? If not, please double-check to ensure all the required types are updated.

Christopher-Chianelli commented 1 month ago
Using Python object for Score allows Python libraries to interpret the
score, allowing the @planning_solution class, justification and
other Python classes that has a score to be used by Pydantic and
the like. This also allows Score | None to be used in type
annotations.

There are some nice Java tests validating the conversion between Python and Java objects. However, I couldn't find any Python code using or testing the new score structure. I recommend adding some domain/tests using medium and bendable scores.

That because all the existing tests (which previously uses the Java score) uses the Python score and weren't change

Previously, parent fields were sometimes added to the instance
field candidate set, causing some fields to incorrectly be None
when unwrapping a PythonLikeObject. Now, all parent fields are
removed from the instance field candidate set.

There are some new tests, but I'm not entirely sure they cover all the behavior added by this change. Am I wrong?

The Score python classes cover this behaviour.

Made toString() call $method$__str__(), and change the return
type of $method$__str__() to PythonString so overrides work
correctly.

I noticed that you didn't update all Python types, such as 'PythonLikeList'. Is there any specific reason for that? If not, please double-check to ensure all the required types are updated.

Generally speaking, only the Python type that overridden toString would need to be updated.

zepfred commented 3 weeks ago
Using Python object for Score allows Python libraries to interpret the
score, allowing the @planning_solution class, justification and
other Python classes that has a score to be used by Pydantic and
the like. This also allows Score | None to be used in type
annotations.

There are some nice Java tests validating the conversion between Python and Java objects. However, I couldn't find any Python code using or testing the new score structure. I recommend adding some domain/tests using medium and bendable scores.

That because all the existing tests (which previously uses the Java score) uses the Python score and weren't change

Okay, I still believe that creating Python classes using the new structure is a good idea, similar to what we did in tests/test_domain.py. Regardless, this is not a blocker if you ensured testing the new score classes locally.

Made toString() call $method$__str__(), and change the return
type of $method$__str__() to PythonString so overrides work
correctly.

I noticed that you didn't update all Python types, such as 'PythonLikeList'. Is there any specific reason for that? If not, please double-check to ensure all the required types are updated.

Generally speaking, only the Python type that overridden toString would need to be updated.

That means the non-updated types will continue using the "incorrect" logic. In this case, we should keep the new logic consistent across all types.

Christopher-Chianelli commented 3 weeks ago

That means the non-updated types will continue using the "incorrect" logic. In this case, we should keep the new logic consistent across all types.

No, the logic for things without toString would be the same.