Enable discovery of type hints as per PEP561 #10
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was wrong?
The
eth_typing
module was born to codify stronger type guarantees for things that previously could only expressed broadly.Example: An API should only accept things of type
Hash32
instead of anybytes
.This worked fine for when we had this module as part of the
Trinity
code base. However, some of these types naturally spread across multiple code bases and hence we created a standalone repository (this one).Unfortunately before PEP561 using type information from 3rd party libraries was pretty much useless and the only way to work around it was to setup stubs and make
mypy
aware of them.Since we didn't have any stubs for
eth-typing
, ironically our effort to limit something as broadly defined asbytes
now becameAny
(without us noticing since we don't have such strictmypy
checks enabled for Trinity yet).How was it fixed?
Configure package to distribute type information to be picked up by mypy in packages using
eth-typing
.Cute Animal Picture