.coveragerc

@@ -0,0 +1,3 @@
+[report]
+omit = 
+    tests/*

.gitignore

@@ -44,6 +44,7 @@ nosetests.xml
 coverage.xml
 *,cover
 .hypothesis/
+*.pytest_cache
 
 # Translations
 *.mo
@@ -70,3 +71,8 @@ target/
 
 # dotenv
 .env
+.idea
+
+# for macOS
+.DS_Store
+._.DS_Store

.travis.yml

@@ -1,19 +1,19 @@
-language:
-  - python
+language: python
 
 python:
-  - "3.4"
+  - 3.5
+  - 3.6
+  - 3.7
+  - 3.8
 
 before_install:
   - git submodule update --remote
 
 install:
-  - pip install six
-  - pip install flake8
-  - pip install ipython
+  - pip install --upgrade -r requirements.txt
 
 script:
-  - py.test
+  - py.test --cov=./
   - python -m doctest -v *.py
 
 after_success:

CONTRIBUTING.md

@@ -1,28 +1,50 @@
 How to Contribute to aima-python
 ==========================
 
-Thanks for considering contributing to `aima-python`! Whether you are an aspiring [Google Summer of Code](https://summerofcode.withgoogle.com/organizations/5663121491361792/) student, or an independent contributor, here is a guide to how you can help:
+Thanks for considering contributing to `aima-python`! Whether you are an aspiring [Google Summer of Code](https://summerofcode.withgoogle.com/organizations/5431334980288512/) student, or an independent contributor, here is a guide on how you can help.
+
+First of all, you can read these write-ups from past GSoC students to get an idea about what you can do for the project. [Chipe1](https://github.com/aimacode/aima-python/issues/641) - [MrDupin](https://github.com/aimacode/aima-python/issues/632)
+
+In general, the main ways you can contribute to the repository are the following:
+
+1. Implement algorithms from the [list of algorithms](https://github.com/aimacode/aima-python/blob/master/README.md#index-of-algorithms).
+1. Add tests for algorithms.
+1. Take care of [issues](https://github.com/aimacode/aima-python/issues).
+1. Write on the notebooks (`.ipynb` files).
+1. Add and edit documentation (the docstrings in `.py` files).
+
+In more detail:
 
 ## Read the Code and Start on an Issue
 
 - First, read and understand the code to get a feel for the extent and the style.
 - Look at the [issues](https://github.com/aimacode/aima-python/issues) and pick one to work on.
-- One of the issues is that some algorithms are missing from the [list of algorithms](https://github.com/aimacode/aima-python/blob/master/README.md#index-of-algorithms).
+- One of the issues is that some algorithms are missing from the [list of algorithms](https://github.com/aimacode/aima-python/blob/master/README.md#index-of-algorithms) and that some don't have tests.
 
-## Port to Python 3; Pythonic Idioms; py.test
+## Port to Python 3; Pythonic Idioms
 
-- Check for common problems in [porting to Python 3](http://python3porting.com/problems.html), such as: `print` is now a function; `range` and `map` and other functions no longer produce `list`s; objects of different types can no longer be compared with `<`; strings are now Unicode; it would be nice to move `%` string formating to `.format`; there is a new `next` function for generators; integer division now returns a float; we can now use set literals.
+- Check for common problems in [porting to Python 3](http://python3porting.com/problems.html), such as: `print` is now a function; `range` and `map` and other functions no longer produce `list`; objects of different types can no longer be compared with `<`; strings are now Unicode; it would be nice to move `%` string formatting to `.format`; there is a new `next` function for generators; integer division now returns a float; we can now use set literals.
 - Replace old Lisp-based idioms with proper Python idioms. For example, we have many functions that were taken directly from Common Lisp, such as the `every` function: `every(callable, items)` returns true if every element of `items` is callable. This is good Lisp style, but good Python style would be to use `all` and a generator expression: `all(callable(f) for f in items)`. Eventually, fix all calls to these legacy Lisp functions and then remove the functions.
-- Add more tests in `_test.py` files. Strive for terseness; it is ok to group multiple asserts into one `def test_something():` function. Move most tests to `_test.py`, but it is fine to have a single `doctest` example in the docstring of a function in the `.py` file, if the purpose of the doctest is to explain how to use the function, rather than test the implementation.
 
 ## New and Improved Algorithms
 
 - Implement functions that were in the third edition of the book but were not yet implemented in the code. Check the [list of pseudocode algorithms (pdf)](https://github.com/aimacode/pseudocode/blob/master/aima3e-algorithms.pdf) to see what's missing.
 - As we finish chapters for the new fourth edition, we will share the new pseudocode in the [`aima-pseudocode`](https://github.com/aimacode/aima-pseudocode) repository, and describe what changes are necessary.
-We hope to have a `algorithm-name.md` file for each algorithm, eventually; it would be great if contributors could add some for the existing algorithms.
-- Give examples of how to use the code in the `.ipynb` file.
+We hope to have an `algorithm-name.md` file for each algorithm, eventually; it would be great if contributors could add some for the existing algorithms.
+
+## Jupyter Notebooks
 
-We still support a legacy branch, `aima3python2` (for the third edition of the textbook and for Python 2 code). 
+In this project we use Jupyter/IPython Notebooks to showcase the algorithms in the book. They serve as short tutorials on what the algorithms do, how they are implemented and how one can use them. To install Jupyter, you can follow the instructions [here](https://jupyter.org/install.html). These are some ways you can contribute to the notebooks:
+
+- Proofread the notebooks for grammar mistakes, typos, or general errors.
+- Move visualization and unrelated to the algorithm code from notebooks to `notebook.py` (a file used to store code for the notebooks, like visualization and other miscellaneous stuff). Make sure the notebooks still work and have their outputs showing!
+- Replace the `%psource` magic notebook command with the function `psource` from `notebook.py` where needed. Examples where this is useful are a) when we want to show code for algorithm implementation and b) when we have consecutive cells with the magic keyword (in this case, if the code is large, it's best to leave the output hidden).
+- Add the function `pseudocode(algorithm_name)` in algorithm sections. The function prints the pseudocode of the algorithm. You can see some example usage in [`knowledge.ipynb`](https://github.com/aimacode/aima-python/blob/master/knowledge.ipynb).
+- Edit existing sections for algorithms to add more information and/or examples.
+- Add visualizations for algorithms. The visualization code should go in `notebook.py` to keep things clean.
+- Add new sections for algorithms not yet covered. The general format we use in the notebooks is the following: First start with an overview of the algorithm, printing the pseudocode and explaining how it works. Then, add some implementation details, including showing the code (using `psource`). Finally, add examples for the implementations, showing how the algorithms work. Don't fret with adding complex, real-world examples; the project is meant for educational purposes. You can of course choose another format if something better suits an algorithm.
+
+Apart from the notebooks explaining how the algorithms work, we also have notebooks showcasing some indicative applications of the algorithms. These notebooks are in the `*_apps.ipynb` format. We aim to have an `apps` notebook for each module, so if you don't see one for the module you would like to contribute to, feel free to create it from scratch! In these notebooks we are looking for applications showing what the algorithms can do. The general format of these sections is this: Add a description of the problem you are trying to solve, then explain how you are going to solve it and finally provide your solution with examples. Note that any code you write should not require any external libraries apart from the ones already provided (like `matplotlib`).
 
 # Style Guide
 
@@ -43,54 +65,27 @@ a one-line docstring suffices. It is rarely necessary to list what each argument
 - At some point I may add [Pep 484](https://www.python.org/dev/peps/pep-0484/) type annotations, but I think I'll hold off for now;
   I want to get more experience with them, and some people may still be in Python 3.4.
 
-
-Contributing a Patch
-====================
-
-1. Submit an issue describing your proposed change to the repo in question (or work on an existing issue).
-1. The repo owner will respond to your issue promptly.
-1. Fork the desired repo, develop and test your code changes.
-1. Submit a pull request.
-
 Reporting Issues
 ================
 
 - Under which versions of Python does this happen?
 
+- Provide an example of the issue occurring.
+
 - Is anybody working on this?
 
 Patch Rules
 ===========
 
-- Ensure that the patch is python 3.4 compliant.
+- Ensure that the patch is Python 3.4 compliant.
 
 - Include tests if your patch is supposed to solve a bug, and explain
   clearly under which circumstances the bug happens. Make sure the test fails
   without your patch.
 
 - Follow the style guidelines described above.
-
-Running the Test-Suite
-=====================
-
-The minimal requirement for running the testsuite is ``py.test``.  You can
-install it with:
-
-    pip install pytest
-
-Clone this repository:
-
-    git clone https://github.com/aimacode/aima-python.git
-
-Fetch the aima-data submodule:
-
-    cd aima-python
-    git submodule init
-    git submodule update
-
-Then you can run the testsuite from the `aima-python` or `tests` directory with:
-
-    py.test
+- Refer the issue you have fixed.
+- Explain in brief what changes you have made with affected files name.
 
 # Choice of Programming Languages