Dev sprint ideas: More tests, type hints and less complexity

@lighttxu

currently, some of the programs use static type checking like this program but some of the programs did not use static typing.

it's a good practice to use static typing as it makes code more clear and readable, should we make it a standard for this repository.we can use mypy for testing code

Dev sprint ideas:

Add tests to Python files with <10% test coverage.
Add static typing to functions and methods.
Set flake8 --max-complexity=15 (Ensure files have strong tests before refactoring). Test results from WIP: Travis CI: Lower flake8 max-complexity to 15 #2139...
- ./boolean_algebra/quine_mc_cluskey.py:82:1: C901 'selection' is too complex (17)
- ./digital_image_processing/edge_detection/canny.py:20:1: C901 'canny' is too complex (17) @lighttxu
- ./graphs/minimum_spanning_tree_prims.py:5:1: C901 'PrimsAlgorithm' is too complex (21)
  - Add doctests aligned with https://en.wikipedia.org/wiki/Prim%27s_algorithm
  - In a separate PR reduce the McCabe complexity
- ./linear_algebra/src/polynom-for-points.py:1:1: C901 'points_to_polynomial' is too complex (23) @nic-dern
- ./machine_learning/linear_discriminant_analysis.py:251:1: C901 'main' is too complex (25)
- ./hashes/hamming_code.py:71:1: C901 'emitterConverter' is too complex (16) hamming_code.py: Reduce McCabe code complexity #2140
- ./hashes/hamming_code.py:153:1: C901 'receptorConverter' is too complex (20) hamming_code.py: Reduce McCabe code complexity #2140
- ./project_euler/problem_551/sol1.py:20:1: C901 'next_term' is too complex (16) Euler problem 551 sol 1: Reduce McCabe code complexity #2141

We push all new contributions to use type hints as discussed in CONTRIBUTING.md.
All efforts to add type hints to existing algorithms would be warmly received.

We can use mypy for testing code

We do this already https://github.com/TheAlgorithms/Python/blob/master/.travis.yml#L17

@cclauss

@cclauss How about a dev sprint kind of thing where we go about adding all such improvements?

Cool idea! Another thing (a sprint topic?) that is bugging me is code complexity which we currently set to 25 but I would be much happier to see it at 15. We would need to ensure that the files have strong type hints and tests before modifying them to reduce their cyclomatic complexity.

Another cool sprint topic would be to add doctests to Python files that have <10% test coverage. Some files like file_transfer/send_file.py and the web programming files are difficult to write tests for but others should be fair game.

Should we have a short sprint or a long one? One idea would be 24 hour sprint — given that tomorrow is summer solstice (longest day of the year) — the sprint could start at midnight tonight (in whatever timezone the contributer is in) and last for 24 hours. #2128 could be our tracking issue for keeping track of tasks and accomplishments. Thoughts on this Summer Solstice Special Sprint idea.