-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make TraitList notify index a plain int where possible #1003
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Using integers as index in clear
, extend
, append
, reverse
, sort
is actually consistent with the behaviour of TraitListObject
in traits 6.0.0.
In traits 5.2.0 and 6.0.0, sorting an empty list emits a notification.
In traits 5.2.0, reversing an empty list does not emit a notification.
In traits 6.0.0, reversing an empty list emits a notification.
It is good we now have tests for these behaviours. The changes from 5.2.0 to 6.0.0 and to the current master show how subtle these changes are.
if index.start is None: | ||
return 0 | ||
else: | ||
return _normalize_index(index.start, length) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still attempting to support whatever was intended when the bug-for-bug implementation was put in place?: cc83835
Is that "bug" still relevant or are we blessing this as a feature?
(I just realized that previously in traits 5.2.0, the bug-for-bug implementation would not have normalized a negative index.start
, though I doubt that was the intended bug-for-bug code.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think there aren't actually any bugs in the TraitListObject
that we need to reproduce at this point, so need for bug-for-bug compatibility. IOW, yes, we're blessing this as a feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And yes, there are going to be some small behaviour changes here. So long as we do the usual level of careful testing with respect to Traits-using projects before we release, I'm happy that those changes don't represent a serious risk of breakage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM!
Will merge this then update #1009 to cope with the resulting conflicts. |
Motivated by #997: this PR changes the
index
used inTraitList.notify
calls to be a plain int, where that makes sense (i.e., everywhere except__delitem__
and__setitem__
operations with an extended slice). I believe that this makes the events more consistent with each other, easier to explain, and easier to interpret for consumers.As a bonus, there's no longer a difference between the
index
,added
andremoved
in theTraitList.notify
calls and the attributes of the correspondingTraitListEvent
s.One other minor change (semi-bugfix) in this PR:
sort
andreverse
no longer notify for zero-element lists. These were the only cases that could produce aTraitListEvent
where bothremoved
andadded
were empty.