Union matches: select type by number of matching fields

[m-aciek]

Closes #263.

[airunderscoreland]

This looks like it safely solves the issue

[m-aciek]

There was an unintended bug in my code. I fixed it with 39d01b7.

Python default sorting is ascending and I wanted to get a quotient of sets. The test passed by accident.

1 {'j'}  # I was getting this element
2 {'i', 'j'}

0 set()
1 {'j'}  # after 39d01b7 (fix) I'm getting this (same element, but the logic is fixed)

[mciszczon]

@m-aciek I'd say this is not a minor change, as it changes the internal behavior of the library: from "match first" to "match best"—which also might not be a trivial thing to say what it means that one structure matches best and not the other.

I could envision this new behavior as an opt-in feature, i.e. union_deep_match=True somewhere to enable deep processing of unions. This would come with a performance hit as well, I believe.

So my proposed solution is:

• implement this deep union matching behind an opt-in flag
• ensure dacite behaves same way as before if no flag is set
• create extensive test suites to cover the new functionality and ensure no incidental breaking changes
• add performance tests to track the performance of deep union matching

I know it's quite a lot and would love to help, but struggle to find the time. Would you be willing to try to add/finish all of the pieces described above?

[m-aciek]

Thank you for the answer.

• add performance tests to track the performance of deep union matching

Do you have some guidelines for the performance tests? How could they look like?

I know it's quite a lot and would love to help, but struggle to find the time. Would you be willing to try to add/finish all of the pieces described above?

I am willing, but also am short with time. Will try to get to it at some point in the future.