Open arubehn opened 1 month ago
@xrotwang, would you agree with this? I would agree, since reverse has a direct use in morpheme segmentation (whwere we use the new classes).
I wouldn't say that either type of reversing is more intuitive, but the clear use case of "going through the list backwards" seems to favor @arubehn 's idea.
I think if we say that slicing only goes for the elements that are addressed, we can have a reverse() function that does a full reverse. But the case of
w = Word.from_segments("a b c + d e f")
w[::-1]
should probably yield:
["d", "e", "f"], ["a", "b", "c"]
Oh, wait. What reverse
function are we talking about? Python's builtin reversed
? Or list.reverse
? Anyway, thinking about these makes me not want a reverse
that does something different. If we need the functionality, we should call it something different.
I was thinking about list.reverse
-- but I think you are right, we might not want to change the behavior of a native function by overwriting it. I still think it would be nice to have this functionality around - so maybe we should just call it something else then, e.g. reverse_segments
?
What about an independent function that just reverts a TypedSequence? It is really for the Word(Morpheme) case, so we can have some short cut:
def revert(word: linse.Word):
return [morpheme[::-1] for morpheme in word[::-1]
reversed_segments
would feel transparent to me - and somewhat in sync with the builtin function being named reversed
.
I'd suggest making the
reverse
function recursive; since I think that is the most common use case. For an exemplary Worda b + c d
,reverse()
would make itc d + a b
, swapping the order of the morphemes, but not the segments inside the morphemes. I think, in the regular use case, you would rather want to end up withd c + b a
.If you agree and think this is useful, I would quickly implement that; as it should be fairly simply.