Make TraitList notify index a plain int where possible #1003
Conversation
There was a problem hiding this comment.
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.
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.
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.
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.
|
Will merge this then update #1009 to cope with the resulting conflicts. |
Motivated by #997: this PR changes the
indexused inTraitList.notifycalls 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,addedandremovedin theTraitList.notifycalls and the attributes of the correspondingTraitListEvents.One other minor change (semi-bugfix) in this PR:
sortandreverseno longer notify for zero-element lists. These were the only cases that could produce aTraitListEventwhere bothremovedandaddedwere empty.