Make TraitListObject use the CTrait to validate items, not the handler

[mdickinson]

This PR fixes TraitListObject, TraitSetObject and TraitDictObject to perform item / key / value validation using the validate method of the appropriate CTrait instance instead of the validate method of the handler. Using the handler's validation is not the right thing to do, because the CTrait validation may or may not delegate to the handler's validate method : in particular, in the case where there's a fast validator, CTrait validation uses that fast validator, and so should the list / set / dict validation.

This fixes one of the issues identified in #1619. (In particular, it fixes the particular example that @mdsmarte gives in that issue.)

Checklist

• Tests
• Update API reference (docs/source/traits_api_reference) N/A
• Update User manual (docs/source/traits_user_manual) N/A
• Update type annotation hints in traits-stubs N/A

[mdickinson]

@mdsmarte Do you have bandwidth for a review?

[mdickinson]

This is a drive-by cleanup unrelated to the PR: the recent PR #1624 added this test to the wrong test class. so I took the liberty of moving it to the right place in this PR.

[mdsmarte]

@mdsmarte Do you have bandwidth for a review?

If you don't mind a short wait, I can take a look mid next week.

[mdsmarte]

The behavior reported in #1619 is now consistent, with both cases now raising an error:

from traits.api import *


class Test(HasTraits):

    foo = Tuple(Int(), Int())
    bar = List(Tuple(Int(), Int()))


Test(bar=[[1, 2], [3, 4]])  # No error on main, error on this branch
Test(foo=[1, 2])  # Error on both main and this branch

However, for the nested case, this is a backward incompatible change... I would hope not a lot of code relies on this, but should we issue a deprecation warning instead of an error?

[mdickinson]

I would hope not a lot of code relies on this, but should we issue a deprecation warning instead of an error?

I'm not really seeing any reasonable way to do that that doesn't also involve a lot of false positives - there's no way for the general machinery to determine when the switch from handler validation to trait validation might make a difference, for example. I think the best we can do is (a) not make this change in a bugfix release (even though it's really a bugfix), and (b) document it clearly in the release notes. The next release of Traits should be a major release anyway, so it's not unreasonable to be making some potentially backwards-incompatible changes (not that we're going to use that as an excuse for gratuitous breakage, of course).

[mdickinson]

I've added an entry for this in what will become the changelog for the 7.0 release.

[mdsmarte]

LGTM!

[mdickinson]

Update: I'm planning a Traits 6.4.0 release; this change will go into that release, rather than straight into the 7.0 release as originally planned. I'll make sure that the release notes contain a prominent note about the potential backward incompatibility.