Skip to content

Chore: consider splitting off our own typing component for internal use #360

Description

@reactive-firewall

Some of the typing annotations are complex, and while tpying will be useful to solving #81 (where less experienced developers may need type hinting), typing is currently unused in development by the maintainers in favor of Python's dynamic typing runtime behavior.

It might be helpful to stuff all of the typing complexities into a focused portion.

Right now the modularizing typing idea is debatably a hasty abstraction...


Best argument considered for typing component

  • typing has become common (:hear_no_evil: love it or hate it, it is a thing)
  • This project has historically been typed
  • Typing is not part of anything else and should be kept D.R.Y.
  • Builds on work from Split single file implementation into python module in pip-licenses/ #316
  • (in theory) Static type checking can catch whole classes of bugs before runtime (e.g., passing an str where an int is expected, misusing None, inconsistent return types). This can reduce defect rates and shorten feedback loops. (albeit data to support this is lacking for pip-licenses in practice)
  • Improved correctness and documentation from the more explicit typing annotations tuned for pip-licenses by consolidating
  • There are good alternatives for things where strong type semantics are important, that could be in the new component (albeit not needed)

Best argument considered against typing component

  • Typing is not enforced in the Python run-time and is intended for the novice Python developer
    • Dynamic types are fully supported by Python but not by existing typing frameworks
    • allow for highly readable code
  • Effort allocation trade-off
    • There is is annotation overhead and maintenance cost already
    • onboarding and cognitive load is reduced by minimal annotations
  • False confidence from incomplete or inaccurate typing is inherent to typing, and a separate component does not solve that
  • There are good alternatives for things where strong type semantics are important, that don't need a new component (albeit those could go into the component)

Metadata

Metadata

Assignees

No one assigned

    Labels

    choreChores are miscellaneous tasks that are neither fixing a bug nor adding a feature.follow-upThis requires some next step(s)questionFurther information is requested

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions