We welcome submission of algorithms and high quality code on all topics concerning quantitative economics.
Less experienced developers who wish to get involved can help improve documentation, contribute notebooks or work on smaller enhancements.
A good place to start is by visiting the project issue tracker
If you are new to open source development please consider reading this page first
The current structure of the
QuantEcon package is relatively flat where python
modules contain most of the code. The majority of methods are available at the top level
namespace for easy access. The python API is defined by the
__init__.py files within the
quantecon package. There is currently one subpackage
modelswhich contains a number of
classes for working with various economic models
One of the advantages of the Anaconda Python environment is that it is cheap to set up (and discard) Python environments for development versions of packages and populate them with your favorite scientific tools. For example, if you’re working on
QuantEcon you might find it useful to set up an environment (containing NumPy, SciPy, etc.) that uses your development version rather than the default ones. This facilitates contributing to
QuantEcon without worrying about corrupting the Python environment on which your other work depends.
Full instructions can be found here
Within the QuantEcon library we wish to maintain a simple and consistent format for inline documentation, known in the Python world as docstrings. The format we use is known as numpydoc. It was developed by the
scipy teams and is used in many popular packages. Adhering to this standard helps us
help(object_name)or the ipython
For full details and examples, this standard is discussed in more detail on this page
Instructions to compile a local version of the documentation can be found here. This can be useful if you would like to check how your docstrings render in html prior to submitting a pull request.
One prerequisite for contributions to QuantEcon is that all functions and methods should be paired with tests verifying that they are functioning correctly. This type of unit testing is almost universal across high quality software projects. This guide is intended to help you get started writing tests for code to be included in QuantEcon.
QuantEcon evolves the current structure will naturally move towards more sub-packages in the future. Every effort should be made to maintain the current API, however if you are submitting a Pull Request (PR) that results in a necessary change to the current API this needs to be explicitly highlighted and discussed as part of the PR discussion through Github