Locally I have passed all test, but seems that Travis can't reach the orings.csv file even if it is present in the git submodule...

I forced the update of the submodule to pass the test, otherwise the test script hasn't the files to process.

@MircoT Great idea using 2to3. I guess it would have been difficult to track down the few bugs left after conversion by the tool. But, there is a little mistake in this PR. The problem with 2to3 is that when you run it on a python2 document it successfully converts it into 3 but when we run it on a document that already has py3 syntax it messes it up. For example in your PR utils.py had print() of py3 type. All of those have now been replaced with print(()). I am not sure what other side effects it might have. I'll suggest that you run it on all files except probabilty.py and utils.py (I guess those are the only ones that have been changed mainly). Cheers!

@reachtarunhere the print errors were my fault (2 passages of the 2to3 tool)... by the way now I corrected them (I think there not will be similar cases like the nature of print keyword in python 2) and I also changed the file collection in a package python, so now you have an installable module and a test folder. It is also ready to be indexed by PyPI if necessary.

I don't know if the last thing is useful but in this way the code is more portable and usable inside other codes.

I want only to apologize for the large number of commits, I hope in the discussion we will figure out if all these changes are good or not.

@MircoT I feel we should not be making the package change to the repo as the general idea is that the repo contains code for the book and not a library. Therefore I guess people do not need to install the package. However we can make a package in the future and link to aima's official site if need be.

And thanks for this PR overall I think it would make the overall job easier for all of us. As a minus we would have to make certain changes as 2to3 recklessly covers map etc. with a list() without considering if we need a list or an iterator would do. Nevertheless this is still better than trying to fix compatibility issues one by one.

@reachtarunhere

• I understand your choice about the package, but consider the following things I have to say
• About the 2to3 conversion is only a shortcut to have a working code fast, obviously we have to do some work to proper cover the code with python 3, for example you can see that I rewritten the maketrans function in encoding because is not present in Python 3, and this is only a small example. I'm glad that it will be useful for the future development.

@norvig I would give you my 2 cents on python package: as we already discussed is better for a programmer or book reader to come here and take what he wants, simply to test thing or see how you could write the algorithms but if all the code is organized as a library those who already have python 3 installed on their computer simply have to install aimaPy with pip and access directly to the code. Furthermore who wants to integrate the library with something, like an app with Kivy or a Qt, can import it in a easy way, also if he needs only a submodule, without care to other dependencies (if there are). Finally a package is a way to contain the code inside a name space and for example in a Jupyter notebook the code will be more readable (and simple to import) because you can separate the modules imported from aimaPy and from standard library, otherwise you will find only import agents instead of from aimaPy import agents. Last but not least unit test will work for the whole package and not for a single module: I mean that if there are some test written for each module and some module have dependencies between them (almost all with utils, for example) is like working with a package, so a collection of modules.

By the way this is only my point of view and I will appreciate so much a response on this because these kind of decisions are common on a development of a project and can change drastically the approach on it.

Cheers!

Thanks for the comments. I'm still not decided; I haven't worked with packages enough to understand them. The idea of being able to do a "pip install aimaPy" is a strong argument in favor of packages. Can you explain to me how the imports would look in a Jupyter notebook, with and without packages? I assume the notebooks would be in another subdirectory, parallel to the code and the tests?

Also, is aimaPy the best package name? I'm open to suggestions.

@reachtarunhere makes a good point that you did good work in applying 2to3, but at some point we should go back and delete "list" calls that are not needed, etc.

@norvig Importing aimaPy would be as simple as import aimaPy. Once imported, you would use it as any other python module.
@MircoT
I am not in favor of converting this repo into a module for the following reasons

1. Increased complexity of the repo structure. I assume that readers of AIMA may not be proficient programmers. Asking them to traverse a library may not be a good option
2. Loss of easy access to source code. By default, when you do a pip install, you download a precompiled version of the package, I believe the latest packaging tool is wheel. For learners who want to have access to the source code to play with, they would have to come here to get it. This defeats the purpose of having a module in the first place.
3. IPython/ Juypter notebooks will have to be distributed separately. This would result in decoupling the source code and the examples. Do we want that?
4. Finally, aima-python was implemented keeping readability in mind. The code mimics the pseudocode in the book. We have not optimized it for speed or memory usage. It might cause performance issues if used in a large project. However, if you need to use a particular algorithm in your project, you might copy the code from the repo directly and the utils.py file if needed.

For the above reasons, I believe that making aima-python a package would not serve its intended purpose.

@norvig I wrote a small example:

# This is how I will import all functions from text module inside the aimaPy
from aimaPy.text import *
# or if I need only shift_encode
from aimaPy.text import shift_encode

print(shift_encode("This is a secret message.", 2))

Another option can be:

# Import only text module
from aimaPy import text

print(text.shift_encode("This is a secret message.", 2))

Or:

import aimaPy

print(aimaPy.text.shift_encode("This is a secret message.", 2))

This is how a notebook file will be if it is present in the main folder of the repository, the same level of aimaPy (otherwise it will not be executed online).

Furthermore those who want to write notebook with aimaPy have to install with pip the package and can access to it from wherever in the system (if correctly installed obviously).

I hope these examples will remove all doubt doubts.

About the name aimaPy was the first thing I had in head, not to long like aima-python could be but with the same prefix of the other version of these algorithms, like aima-java etc... Also it might works aima as a name for this package, so you can list the submodule like aima.agents and so on.

Anyway for my point view the best score to adopt the package configuration is the better management of the library (also for future dependencies and current relative imports), the organization of the tests, the creation of a "namespace" for all the modules and the online propagation (with pip you only need python installed).

@gokul-uf

1. is not too complex, is all in a folder and you have to understand python import to code in python, so is a requirement for anyone want to understand these algorithms, even if you want just copy and paste this code
2. we can include the plain sources and the repo online is always visible. Also a good Python doc is required to be a good package
3. they can be inside aimaPy or in the main repo folder and if you install the package users can access wherever in the system
4. I find the package way more readable and portable instead a copy-paste code (this is what I was looking for at a collection of such modules when I showed them the first time)

I agree with these changes, they make code more python friendly|
@gokul-uf
1° It's more simple (if you know python).
2° You can use pip, you can use github zip download, you can copy files (these changes don't limit such posibilities)...
3° What?
4° Creating a package doesn't change "speed" and makes code more readable!

1. If you know python - Can't make that assumption about the learners
2. I wasn't referring to limiting any possibility. I was referring to the fact that if you want to learn, you need the source code. Making a package doesn't make accessing the source code any easier. On the contrary, it makes it difficult.
3. I have not seen IPython books being made available as part of a package. You need to have both examples and source code together. Packing aima-python does the opposite
4. Please carefully read what I have written earlier

Cheers!

1° For a beginner add or change the code into package directory or in other directories isn't a big change.
And if you aren't a Beginner you can find this structure more comfortable.
2° Open a directory and copy a file isn't more difficult to copy a file. If you are a Beginner you can download the repo from GitHub and use this in the same way.
3° You can use iPython notebook with the package without a problem.....
4° An organized package is better than a folder full of files, despite of the compiled source or not.

Write a good(with a good structure) code is best way to understand a code (This my thought).

@gokul-uf after the installation of the package the sources are available in the site-packages folder as all Python module; there you will have an aimaPy directory with the same files of the repo. Obviously you have to write a correct MANIFEST.in to include other sources like Jupyter notebooks, but is always possible.