Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Heyo Gitcoiners! With an entire city of hackers, coders and blockchain innovators relocated on our platform, the atmosphere is just buzzing with crea…
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
[Type hints](https://www.python.org/dev/peps/pep-0484/) allow us to perform static type checking, among other things. They raise the security bar by catching bugs at development time that, without type support, may turn into runtime bugs.
[This stackoverflow answer](https://stackoverflow.com/questions/32557920/what-are-type-hints-in-python-3-5/32558710#32558710) does a great job at describing their main benefits.
### What is wrong?
We currently enforce type hints for the entire `p2p` and `trinity` package. While the `eth` package does have some type hints already, the coverage isn't at 100 % and while it is agreed up on that new code needs to land with type hints, there is not technical enforcement of this rule in place yet.
This needs to be fixed by:
1. Adding all missing type hints.
2. Enforcing (stricter) type checking in CI
There does exist tooling ([monkeytype](https://engineering.instagram.com/let-your-code-type-hint-itself-introducing-open-source-monkeytype-a855c7284881)) to the generation of type hints for existing code bases. From my personal experience `monkeytype` *can* be helpful but does still require manual fine tuning. Also, manually adding these type hints does serve as a great boost to the general understanding of the code base as it forces one to think about the code.
1. Run `mypy --follow-imports=silent --warn-unused-ignores --ignore-missing-imports --no-strict-optional --check-untyped-defs --disallow-incomplete-defs --disallow-untyped-defs --disallow-any-generics -p eth`
2. Eliminate every reported error by adding the right type hint
3. This should probably be done incrementally in roughly the following steps.
- `eth.tools` (eligible for payout of 150 DAI)
- `eth.vm` (eligible for payout of 350 DAI)
- everything that is not `eth.vm` (eligible for payout of 300 DAI)
The reason for this order is, that it makes it easy to incrementally update the `tox.ini` to enforce stricter rules for such each package without cluttering `tox.ini` too much.
4. Send frequent pull requests for chunks of work
### Definition of done
This issue is done when the following criteria are met:
1. The following configuration in `tox.ini` is changed.
It needs to be:
mypy --follow-imports=silent --warn-unused-ignores --ignore-missing-imports --no-strict-optional --check-untyped-defs --disallow-incomplete-defs --disallow-untyped-defs --disallow-any-generics -p eth
2. Usage of `type: ignore` (silencing the type checker) is minimized and there's a reasonable explanation for its usage
### Stretch goals
When this issue is done, stretch goals can be applied (and individually get funded) to tighten type support to qualify:
1. `mypy --strict --follow-imports=silent --ignore-missing-imports --no-strict-optional -p eth -p p2p -p trinity`
2. `mypy --strict --follow-imports=silent --ignore-missing-imports -p eth -p p2p -p trinity`