Currently, all fields in Mentor and Mentee classes, including timestamp and techtopicinterest are strings. Let's use more appriorpiate data types for storing this data.

Currently the code relies on tuples a lot. It is not a good coding practice for many reasons. Introducing mentee and mentor objects will make the code easier to write and maintain.

$ python3 mentee_mentor.py -f  
usage: mentee_mentor.py [-h] [-n COUNT] [-f_mentee MENTEEFILE]
                        [-f_mentor MENTORFILE] [-t] [-v] [-r] [-u] [-m]

1. -f_mentee and -f_mentor are long while others are not long
2. some parameters are mandatory, not optional but still shown as optional

If a user does not specify how many random lists to generate, use some reasonable default value.

We want to foster the community of mentors. So, if a mentor volunteered, we don't want to say: "hey, you know, we don't need your help this time"

In this mode, mentees could get multiple mentors assigned. The idea, essentially, is to use the full capacity of the mentors to help as many mentees as possible.

Note, the disadvantage of this approach is that we cannot add more mentees later or accommodate situation when a mentor is suddenly not available. Maybe leave a few mentor slots not occupied?

Currently it is hard for a user to quickly get a sense of how good is the list. Producing the following table will help:

Mentee     | Mentor       | In-person-virtual match | Industry-Academia Match | Not same institution | Topic Match |
John Smith | Angela Davis |        x                |           x             |       x              |    x        |
Peter Cool | Camilla Uga  |        x                |           x             |       x              |     -       |
...

This is useful for cases when more mentees are registering late.

We want to match people who are otherwise not likely to meet.

Every mentee has a preference of talking either to industry or academia representative. Every mentor specifies his or her affiliation with either industry or academia. Implement mentee-mentor matching that ensures that mentee's preference is respected.

Currently, parse_mentor() and parse_mentee() are functions in mentee_mentor_class module. It makes sense to convert these functions into @classmethod methods for Mentor and Mentee classes. These methods will act as secondary constructors for the classes. This should be analogous to how fromfilename() is implemented here:

Is it not possible to define multiple constructors in Python? [duplicate]](https://stackoverflow.com/questions/2164258/is-it-not-possible-to-define-multiple-constructors-in-python)

If mentee A was mentored by mentor Z in 2022, there is a good chance we don't want the same pairing to happen in 2023.