-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Finished porting to Python 3 #93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Used tool 2to3 to finish the porting to Python 3 plus some fixes by hand.
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. |
@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
For the above reasons, I believe that making |
@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).
|
I agree with these changes, they make code more python friendly| |
Cheers! |
1° For a beginner add or change the code into package directory or in other directories isn't a big change. 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. |
Used tool 2to3 to finish the porting to Python 3 plus some fixes by
hand.