Decide whether to add type hints to coding standard

Background

Type hints have been valid syntax in Python since 3.0 (PEP3107) and given more meaning since 3.5 (PEP 484).

An example function declaration with type hints:

    def import_files(self, external_pathspec: any, files: List[str] = None,
                     report_written: bool = True, update_utimes: bool = False,
                     can_link: bool = False) -> FileListResult:

@jmacarthur, @juergbi and @tristanvb are keen on having type hints in BuildStream, but we should add this to the coding style of the project if we're going to use them.

The goal is not to automatically check types immediately, but to increase readability of code and allow for type checking in future.

We currently require function arguments and return values to be documented in comments in certain places, but this has not been applied consistently in the code. This would move the same information to a more machine-readable form.

Task description

• Collect opinion on whether to require type hints.
• If agreed on, add that standard to HACKING.rst.

Acceptance Criteria

Either we agree not to add type hints yet or add it to the coding standard.