Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add static type information #21

Open
Technologicat opened this issue Aug 14, 2019 · 2 comments
Open

Add static type information #21

Technologicat opened this issue Aug 14, 2019 · 2 comments
Labels
discussion Thinking it over - comments welcome! enhancement New feature or request
Milestone

Comments

@Technologicat
Copy link
Owner

While useful, this is difficult to do for features like curry and with continuations.

Some selected parts of unpythonic could be eventually gradually typed using mypy, but this is not being worked on at the moment.

See #8 for context.

If anyone feels like working on this, in principle I'm open to suitably scoped PRs adding type signatures to parts of the library (using Python's type annotations) - but perhaps post a comment here for discussion first, to converge on a definition for "suitably scoped".

@Technologicat Technologicat added enhancement New feature or request discussion Thinking it over - comments welcome! labels Aug 14, 2019
@Technologicat Technologicat added this to the milestone Aug 14, 2019
@Technologicat
Copy link
Owner Author

Now that we have @typed to perform dispatching and yell if the argument types are wrong, that could synergize:

  • Get runtime type checking with compact syntax, allowing us to delete some if not isinstance() ... raise TypeError ... boilerplate.
  • That compact syntax is the type annotation syntax used by mypy, so allow static type checking for no extra effort.

Investigate in 0.14.3. Maybe do it for a few select modules such as unpythonic.it and unpythonic.fold.

@Technologicat Technologicat modified the milestones: , 0.14.3 Aug 28, 2020
@Technologicat
Copy link
Owner Author

Forgot to mention, this allows us to delete not only the isinstance boilerplate that performs runtime type checking, but also the automated tests for individual instances of that boilerplate. The @typed machinery is tested centrally, so we can rely on it.

This is one reason it's useful to have a gradual typing mechanism (using some kind of type annotations) as a language feature in a dynamically typed language... sure, one can achieve the same effect in any Turing-complete language even without such a mechanism, as Python programs often do, but having a mechanism to compactly express this very common intent makes programs shorter, and more readable.

(Having language support reduces the impedance mismatch between what the source code says and what the programmer means. Arguably, the types are part of the call signature, so the logical place to express the type check is as part of the function's API; not hidden inside the function body so one has to look at the implementation (or at the docstring).)

@Technologicat Technologicat modified the milestones: 0.14.3, 0.14.4 Sep 11, 2020
@Technologicat Technologicat modified the milestones: 0.14.4, Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Thinking it over - comments welcome! enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant