Fix RevPrefixMap to inherit directly from TraitType#1098
Conversation
|
Actually, let me do at least a little bit of cleanup in the |
Done. |
| self._map = {key: key for key in self.map} | ||
| self._rmap = {value: key for key, value in self.map.items()} | ||
|
|
||
| if default_value is None: |
There was a problem hiding this comment.
We may be able to simplify this - it looks as though for all current use-cases of RevPrefixMap, there will always be a default value present (so we can make it required rather than optional in the signature), and that default value doesn't itself need completion - it'll be one of the keys of the map.
But that simplification would be a behaviour change, and I'm reluctant to make such a behaviour change in a bugfix release.
|
|
||
| matches = [key for key in self.map if key.startswith(value)] | ||
| if len(matches) == 1: | ||
| self._map[value] = match = matches[0] |
There was a problem hiding this comment.
Traits 6.3.0 removed the caching from PrefixMap. We could do the same here. (But again, this would be a behaviour change that shouldn't be made in a bugfix release.)
|
Sorry, @rahulporuri. In case it wasn't clear, I'm done tinkering with this PR. (There's lots more I'd love to do given time, but I don't have that time right now, and this seems like it should be enough for the bugfix.) |
2 participants
This PR rewrites
RevPrefixMapto inherit directly fromTraitTyperather than subclassingPrefixMap. This reduces the fragility ofRevPrefixMapwith respect to future upstream changes toPrefixMap.To get to this code, I simply pasted in the Traits 6.2.0 version of
PrefixMapunder a new nameOldPrefixMapto remove the dependence on upstream, and then refactored to collapse theRevPrefixMap -> OldPrefixMap -> TraitTypeinheritance tree toRevPrefixMap -> TraitType.I've added some extra tests, to be sure that I didn't break existing behaviour while refactoring.
There are plenty of further cleanup and refactoring opportunities in
RevPrefixMap(particularly in the__init__and with the duplication betweenvalue_forandvalidate), but those are probably best left to the next minor feature release. I'm hoping that this PR can go into the 4.7.4 bugfix release.Fixes #1094.