From 19.0.3 to 20.0.1 matching blocks now return empty list if no match found about levenshtein

[maxbachmann]

This is fixed in v0.20.2

[maxbachmann]

I hope MatchingBlock behaves similar to a tuple. If some tuple feature is missing this would be an issue.

[maxbachmann]

Ah you mean for the empty case. I think this could be a bug. I will look into it tomorrow.

[maxbachmann]

I failed to reproduce this in my phone. Do you have an example?

[Otterpatsch]

Mhm i dont really have an example i can share. So you dont get an empty list on empty matching blocks? Than my idea is false. I dont want to alarm you but i did update to the new version and did fix the code on my side (like being depending on the last element for the information of the strings) but now our piplelines are failing which are using this code.(nothing else changed) So what is matching on a lot of string comparisons and stuff changed for some reason. Soo yeah i will be swap back to 19.0.3.

Here is the usage of your functionality in our code

`def _get_matching_blocks(query: str, text: str) -> list[tuple[int, int, int]]:
"""Get matching blocks between to strings."""
edits = Levenshtein.editops(query, text)
return Levenshtein.matching_blocks(edits, query, text)

def _get_matching_ratio(query: str, text: str) -> float:
"""Calculate how much of query is also contained in text."""
matching_blocks = _get_matching_blocks(query=query, text=text)
fragmentation_penalty = -len(matching_blocks) + 1
return (
2 * sum(match[2] for match in matching_blocks)
- len(query)
+ fragmentation_penalty
) / len(text)`

[maxbachmann]

Ah I just tested rapidfuzz, since the Levenshtein library currently fails to install in termux (I did not apply the fix I implemented in rapidfuzz here yet). Looking at the code it appears the following line causes this issue: https://github.com/maxbachmann/Levenshtein/blob/aa4711fc2963f8a9947c69d7fe0210abbb30cb35/src/Levenshtein/__init__.py#L158

[Otterpatsch]

alright makes sense.