DSDE-204: Finalize the pyramid matching code

[lgarridobsq]

Esteban's efforts to make a Class into the Pyramid matching.

Leaving as a Draft PR, since it is not yet ready to be merged and available to users.

[lgarridobsq]

Hola @EstebanMontandon !

I have adapted your matching code. Basically, I have:

• Corrected some Python types
• Added the threshold as a parameter. (I think this is important -- it will allow us to be a bit more flexible. I think it makes a lot of sense to have all of the things that are needed for a particular matching method inside the matching class as attributes. This way, we do not need to pass variables through when doing the matching: it is all already there).

Apart from that, I have touched a bit my code. Basically, I have made it so that you pass the logger through -- this way, we can call the method from whatever code and it will pass the logger... I am not sure what to do if no logger is passed through: I can either create a new logger, print the messages (this might be useful if running the function in a notebook) or do nothing (this is what I do now).

We also need to discuss how the function is going to be called. From my side, honestly, I would leave it as a function: I think it is the easiest way to call it: you just call the function feeding it a pyramid + something to be matched and then it spits out the results -- and if you need to make it more concrete, you can.

On top of that, I would put it on the toolbox + add a readme. The readme should include how to run the function teoretically + some examples. I think with this, the function should be usable enough.

Tell me what you think. In my head, before shipping this off, we need to:

• Finalize the discussion on how to run the code
• Merge this in the toolbox
• Add the README.md
• Finalize the tests (¡thanks for doing them! I am aware I ruined some of them -- I can work on this once we have a more concrete idea of what we want)

Sorry for the long text -- I am available for a call if you think it will be more useful.

[EstebanMontandon]

Excellent. I’ll take some time to review the functionality again in the next sprint, where we can discuss potential changes and design improvements. For now, we can merge and check in future iterations.

Thoughts & next steps , I think we should:

• Think about the logging/summary process.
• I believe that encapsulating the logic in a class allows us to maintain execution state (e.g; progress, intermediate results, configuration, and errors), which a standalone function cannot manage cleanly. Why not return only 1 result (dataframe) and everything else gets stored in an internal summary variable that collects all details about the process from the class itself?
• I like your approach about the logging. I think if no logger is passed, we just print or something. The summary process should contain all details anyway, this could give some flexibility to the user to choose how to print as well (related point above).
• Let’s think about how we can improve the results so they are clear, concise, and easy to understand (does any of the columns need renaming/clarification?, some formatting consistency with inputs (strings are modified to facilitate the matching, should they keep their original format?).
• Include tests for the matching class: We should not include this code into any existing toolbox if we don't have the functionality properly tested.

I think we are in the way to produce some quality stuff here! we just need to continue iterating :p