Consider creating a python api as an alternative to creating signatures with JSON. At the moment we conflate signature specifications and data together a bit - e.g. generate_by_char_at(attr_ind: int, dtuple: Sequence, pos: List[Any]) requires the specification for the signature in attr_ind.
Possible example using names from #48:
signatures = [
FirstWordSig('street') & InitialLastWordSig(name) | 128,
ExactMatchSig("postcode") & WordSoundSimilarSig('name') | 128,
ExactCharMatchSig("firstname", 0) & ExactCharMatchSig("surname", 0)
...
]
Key points for usability would be using the field name instead of the index and easily being able to compose together a signature spec. Here the binary operators __and__ and __or__ could be overloaded to chain together signature specs, of course this could be done in many different ways.
A builder pattern might be something like:
Signature()
.add(ExactMatchSig("postcode"))
.add(WordSoundSimilarSig('name'))
.filter(128)
(I don't like this way but want to put a few ideas up)
Consider creating a python api as an alternative to creating signatures with JSON. At the moment we conflate signature specifications and data together a bit - e.g.
generate_by_char_at(attr_ind: int, dtuple: Sequence, pos: List[Any])requires the specification for the signature inattr_ind.Possible example using names from #48:
Key points for usability would be using the field name instead of the index and easily being able to compose together a signature spec. Here the binary operators
__and__and__or__could be overloaded to chain together signature specs, of course this could be done in many different ways.A builder pattern might be something like:
(I don't like this way but want to put a few ideas up)