If possible, we can try making asynchronous GET requests for faster outputs.

While getting the categories for a wiki page, we can provide whether we need hidden categories or not as mentioned here. This needs to be implemented in the existing code wiki_cat.py#L14. This should be sent as parameter to the get_cat function. For example,

def get_cat(self, pageid=None, include_hidden=False)

As mentioned in the MediaWiki API:Etiquette.

This would involve the following:

• Document the source code (module, classes and the methods)
• Generate documentation using a well known tool like Sphinx or something else
• Host it on https://readthedocs.org/

Refer to http://docs.python-guide.org/en/latest/writing/documentation/ for details on how to do the above.

There are many things that can be improved

• Create a proper module
• Do proper exception handling and create new exceptions if needed
• Currently there is a class WikiCatQuery whose object needs to be instantiated before making any queries. This makes it closed to any extensions. By this logic a new class will have to be added for every new feature, which is wrong. Make an interface with WikiPage class where you only add a method for a new feature. (Resolved in #19)

Now that the project involves more than just categories. I would like to hear suggestions on what should it be named.

This would aim to minimize calls to the API for repetitive requests. The idea is to use the information which has already been obtained from the API for a second query of the same page. There are many more concerns like how long before the cache expires etc which can be further discussed here if anyone is interested.

Use a testing framework and setup simple tests that can be run on Travis CI.

Package the code so that it can be published on PyPI and hence is available for installation through pip. Making it available as a conda package is optional.

Refer http://docs.python-guide.org/en/latest/shipping/packaging/

Checklist of all API properties for reference:

• images
• linkshere
• categories
• categoryinfo
• contributors
• deletedrevisions
• duplicatefiles
• extlinks
• fileusage
• imageinfo
• info
• iwlinks
• langlinks
• links
• pageprops
• redirects
• revisions
• stashimageinfo
• templates
• transcludedin

Rearrange the source files into appropriate folder structure. This link can be referred for best practices: http://docs.python-guide.org/en/latest/writing/structure/

The response of linkshere is huge and it blocks the execution till it returns. So instead of setting the limit as max it would be good to set it to something reasonable and wrap it in a generator.

Currently the code takes only the page id as the input which is not very user friendly. This would involve adding more options like querying by wikipedia link or page title.

See https://www.mediawiki.org/wiki/API:Query for more information on what input does the MediaWiki query take.

An isolated environment to which developers can switch and then start contributing. I would prefer Python 3 environment. This might also require minor refactoring of the code too.