Keep _constraint and _pretty_constraint of Dependency synchronized when calling set_constraint()#214
Conversation
neersighted
left a comment
neersighted
left a comment
There was a problem hiding this comment.
Is there a compelling reason we can't remove the internal property and rely on the getter to call str()? I'm not super familiar with the code here, but this just seems to be much more error-prone than computing the value on demand.
radoering
force-pushed
the
keep-pretty-constraint-in-sync
branch
from
bb469a8 to
a4dc4eb
Compare
|
The only reason I can imagine (without having examined it) is performance. |
|
Let's go ahead and drop the property then -- I think that implementation will be much more obviously correct and will not allow things to get out of sync in the future. |
|
After dropping the property, I had to adapt some tests because the constraint style changed. With the property pretty_constraint was determined before parsing the constraint, now it is determined after parsing the constraint. |
Gah, looks like it's a pretty leaky abstraction overall. I'm inclined to just roll back to your first changeset and plan to refactor this later. |
…t from _constraint"
|
No problem. In any case, less risky. |
2 participants
Resolves: python-poetry/poetry#4589