PyLNP Developer Reference

This document will describe PyLNP from a developer’s perspective.

Licensing

PyLNP is licensed under the ISC license (see COPYING.txt), which essentially allows you to modify and distribute changes as you see fit. (This only applies to the launcher. Any bundled utilities, graphics packs, etc. have their own licenses; refer to those projects separately.)

Acquiring the source code

The source code is available at Github.

If you wish to contribute to PyLNP development, a pull request will be much appreciated.

Coding guidelines

  • All code should be compatible with both Python 2 and Python 3. The reason for this is mainly to ensure as much compatibility as possible. Python 2, in particular, is required for building binaries.

  • All source files must start with the following preamble (followed by a blank line for separation):

    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    """<module docstring>"""
    from __future__ import print_function, unicode_literals, absolute_import
    
  • As a rule of thumb, PEP 8 should be followed. In particular, pylint should return no errors or warnings when run on the source code (using the provided pylintrc file). Any and all messages generated by pylint must either be fixed or explicitly suppressed on a case-by-case basis. Formatting-related messages (line length, indentation, etc.) must always be fixed. Examples of valid suppressions:

    • PyInstaller requires a certain package to appear in an import statement in order to create working binaries, but the statement doesn’t need to actually run at any point in time. Here, it is valid to place the import statement in an if False: block and suppress the resulting using-constant-test message.

    • A package needs to be imported with a different name in Python 2 compared with Python 3. Here, the resulting import-error message should be suppressed.

    • Inner functions defined for the purpose of callbacks are permitted to not have docstrings, but the warning for this must be suppressed for the individual function.

  • PyLNP is divided into two main components: core, which is the main application, and tkgui, which represents the UI. The UI must only perform non-UI work by calling into functions of the core library. This is to simplify implementation of alternative user interfaces. Where possible, core methods should not call into the UI; in cases where this is unavoidable, the method must be documented in the UI class defined in lnp.py.