Fix type annotations with using type.List.

[azriel1rf]

Fix type annotations in Python for issue #75
This pull request addresses the type annotation errors raised by mypy when running mypy .. The necessary changes have been made to resolve these errors.

Additonal Notes:

• We should consider defining and documenting a set of linters that our project should adhere to. These linters can be integrated into our GitHub Actions workflow using tools like the Super-Linter (https://github.com/marketplace/actions/super-linter).
• Python 3.7 has been deprecated in this pull request. For more information on Python version support, please refer to the Python Developer's Guide: https://devguide.python.org/versions/

[HenryRLee]

Hey @azriel1rf, nice to see you back!

The PR looks good to me. Ready to merge.

My question is, does this change break our library in Python3.7? If it does, we may have to increase the major version number (i.e. 0.6.0) when we release a new package. Also, maybe it is a good time to start using different versioning in our Python and C++ library. (Since C++ has already been in 0.6.0 with new PLO5 and PLO6 features, and some features deprecated.) But these are the next steps.

[azriel1rf]

To clarify, this change doesn't affect Python 3.7 functionality, as the type annotation issue is specific to versions below 3.9. However, I removed Python 3.7 support since it has reached end-of-life.

Regarding versioning, while incrementing for language-specific features may seem frequent, we should consider the impact on users.

How about creating a development branch as a staging area to merge and test changes before releasing to the master branch? This will ensure a more controlled release cycle and consistent versioning.
What do you think about this approach? Let me know if you have any further ideas or concerns.

[HenryRLee]

Hi @azriel1rf, I think your approach is good. I didn't choose this approach previously because I found it overfitting for this small repo. However, since now we have multiple languages and increasing number of bug fixes and features, it is time for us to change the style of managing the repo now.

The only catch is that we need to make sure contributors are checking out the code in development branch. I'll add a note in the CONTRIBUTING.md file.

Let me merge this PR, and then I'll create a development branch named develop.

[azriel1rf]

@HenryRLee Thanks!

[azriel1rf]

@HenryRLee Thank you for creating the develop branch. I appreciate your support in implementing this new development workflow.
One important thing to consider is updating our CI configuration in ci.yml. We need to ensure that the CI pipeline is triggered for pushes and pull requests to both the master and develop branches.