pyscaffold / configupdater

98%

master: 97%

LAST BUILD ON BRANCH add-type-hints

branch: add-type-hints

CHANGE BRANCH

x

Reset

• add-type-hints
• HEAD
• add-adopt-option-test
• add-fallback
• add-missing-type-hint
• add-py-typed
• api_token
• attach-container
• badges_template
• cleanup-insert
• clear-remove-all
• deepcopy-option
• deepcopy-section
• deepcopy-toplevel
• dev
• fix-type-errors
• fix15
• fix_liskov
• fix_option
• fix_retval
• fix_setitem_in_document
• fix_type_errors
• improve-errors
• improve-optionxform-issue
• improve-validation-consistency
• issue-10
• issue-31
• issue-55
• issue-68
• link-missing
• main
• make-add-line-protected
• markdown-everywhere
• master
• mention-deepcopy-docs
• ml-comments
• modify-multiline-values
• pre-commit-ci-update-config
• psf-license
• pyscaffold-update
• pyscaffold-v4
• reorganise
• section_comment
• simplify-coverage
• type-improvements
• update-ci
• v0.1
• v0.1.1
• v0.2
• v0.3
• v0.3.1
• v0.3.2
• v0.3.2rc2
• v1.0
• v3.0
• v3.0.1
• v3.0rc1
• v3.0rc2
• v3.1
• v3.1.1
• v3.2
• v3.2b1
• work-on-optionxform
• workaround

Build # #153

Build Type

push

coveralls-python

Committed by abravalheri

Commit Message

Add type hints (mypy assumed as reference/standard)

This is an attempt to start addressing issue #16.

Adding type checking to an untyped codebase is usually a challenge and
sometimes require pragmatic approaches, such as the one adopted in this
commit.

`# type: ignore` is used sporadically, but is still present when the
type checker is not "smart enough", when the current Python syntax does
not allow expressing the most correct type information or when it was
too hard to introduce it.

It was necessary to remove explicit inheritance from `MuttableMapping`,
since the abstract methods are being overwritten with a non matching
signature that is more convenient for ConfigUpdater.

Functions that use `_UNSET` are currently not completely well typed,
it is still necessary to find an alternative (can we consider `Optional[T]`?)

---
As a quick report, the process used to produce the type annotations was
"semi-manual", with the following steps:

1. Using `pytype` as type checker, the type errors were debugged and
   fixed or "workaround"-ed
2. Using `pytype`, initial type stubs were created
3. Using `retype`, the type stubs were merged back into the source code
   (for some reason `pytype`'s `merge-pyi` did not work)
4. Manual checking/refactoring/fixing of the annotated file
5. Introduction of new annotations not generated by `pytype`
6. Using `mypy` as type checker, the type errors were debugged and fixed
   or "workaround"-ed

mypy does seem to have a tool for generating type stubs, but I have
never worked with it...

Run Details

225 of 237 branches covered (94.94%)

Branch coverage included in aggregate %.

572 of 580 relevant lines covered (98.62%)

0.99 hits per line