Unfeature: disallow "*" in a nonterminal position in the observe mini-language #1525
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR #1496 introduced
"*"
to mean "any trait" in the observe mini-language. But a "*" in anything other than a terminal position (for example, as inmy_obj.observe(handler, "*:updated")
is hard to use, thanks to a combination of two things:trait_added
andtrait_modified
, and so typically includes at least some traits for which the following expression won't apply well -trait_added
is anEvent
trait, and its value doesn't have anupdated
traiton_trait_change
won't complain about trying to set up a listener for theupdated
trait on an object that doesn't have anupdated
trait (and possibly isn't even aHasTraits
instance);observe
will.There may be a better meaning for
"*"
in a non-terminal position - for example, we might consider that after a"*"
, the following expression is treated permissively (using something like the existingoptional=True
).For now, we make a
"*"
in a non-terminal position illegal, so that we have the freedom to re-add it later with better behaviour. (Note that the"*"
feature has not yet appeared in any released version of Traits, so there are no backwards compatibility issues here.)Closes #1505
Related: #1503