Trait Owner Agnosticism

[rmorshea]

In general there's confusion throughout traitlets about what characteristics of traits are or aren't known independently of the class / instance they belong to. As a result, there are many places in the codebase that are effectively copying and posting code from validate(self, obj, value) into their __init__ because obj isn't known at that point. The same is true of default value representations which attempt to get default_value even though the trait may have a make_dynamic_default method, and or get cast via validate after the fact.

In an ideal world, traitlets would have been designed with this gnostic dichotomy in mind, and we might have been able to do Int.validate("one") or repr(List.default()) reliably. Unfortunately though we're stuck in a world where it wasn't. As a result, I would propose that we remove tests that check for valid defaults in the constructors of traits (e.g. Tuple(default_value=5) would not raise) or string representations that use default_value. The former case makes it difficult to generalize much of the logic in traitlets, while the latter is simply misleading.

I'm not sure how tenable this proposal is, but this problem is pervasive in traitlets and makes it increasingly difficult to improve traitlets without breaking these problematic expectations.

[ankostis]

I think know the drill a bit(eg #389, #287).
I guess you propose simply to drop the test-cases; not to completely stop invoking validate() on plain defaults, correct?

[rmorshea]

@ankostis, just to be sure we're on the same page - there is currently no way to use the public or private API of traitlets that would allow you to retrieve the "true" default value for a trait without knowing its owner.

As a result, I would propose that we remove tests or features that act as if this were possible.

This would include (but may not be limited to):

1. Tests that expect Tuple(default_value=5) to raise.
2. Tests that expect Tuple(default_value=[]).default_value_repr() == "()".

[rmorshea]

In a world where backwards compatibility didn't matter we would instead move to enforce a kind of public/private parity for owner gnosticism:

def validate(self, value):
def _validate(self, owner, value):

def default(self):
def _default(self, owner):

def cast(self, value):
def _cast(self, owner, value):

With this kind of pattern we could do t.validate(t.cast(t.default())) and have the "true" default for a trait.

[minrk]

Since validations are necessarily tied to instances in general (otherwise @validate methods are ignored), I'm not sure how trait.validate could ever work without an instantiated object, unless you are deciding ahead of time that it should only be a partial validation, not a 'real' one. The only other option would be to take away the ability to have custom validation methods, which we also can't do.

I'm not sure there are any actions to take here here, other than acknowledging a downside of some choices that we cannot change for backward-compatibility.

I don't believe we should be removing any of these tests, as there may be code that relies on it, whether we like it or not, and backward-compatibility, even for unintended quirks, is of utmost priority for traitlets. I know this makes developing and improving traitlets in these ways difficult and frustrating, and that's why I don't believe anyone should be making such efforts.

[rmorshea]

Closing to make it easier to find immediately relevant issues.