Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add static type checking with mypy

Aperta
  • Qualcosa non va?
#212 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
67/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
fastapi, python
Ambito
authentication, backend, ci-cd, devtools, documentation, testing

Direzione di ricerca

Start with uv run --with mypy mypy app --strict, then inspect the listed locations in app/pesu.py, app/app.py, and app/docs/base.py. Read pyproject.toml, the pre-commit configuration, lint.yaml, and the Linting & Formatting section of CONTRIBUTING.md. Done means strict mypy passes, the empty CSRF case is tested, CI and pre-commit run it, and all acceptance criteria are met.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement tests and ci/cd

🔄 Updated for v5.0.0 (2026-10-08). Still open. 5.0.0 (#241) rewrote app/pesu.py, so the original findings, including the CSRF token bug, no longer exist. The table below is a fresh mypy run on 5.0.0: 9 errors, none of them a runtime bug today. Lint now runs in the Package checks job of ci_checks.yml, so the CI steps are updated too.

Summary

Every function in app/ has type annotations (ruff's ANN rules enforce it), but nothing checks that the annotations are true. A trial run of a type checker over app/ finds places where the annotations and the code disagree. Add mypy in strict mode, with the pydantic plugin, fix what it finds, and run it in pre-commit and CI.

What a type checker finds today

Re-run on 5.0.0 (dev at 01522de) with the configuration proposed below (strict, with the pydantic plugin), mypy reports 9 errors in 3 files. Without the plugin it reports 11, because it can't see field aliases such as instituteName, so use the plugin.

Where Finding What to do
app/models/upstream.py, UpstreamDetails._none_if_invalid info.field_name is str | None, passed to pesu_name(str) pydantic always sets it for a field validator, but the types can't show it. Narrow it explicitly rather than ignoring the error.
app/models/upstream.py, LoginResponse._no_token_if_invalid returns Any (the handler's result) where str | None is declared Narrow or cast the handler's result, with a comment.
app/app.py, _restore_documented_examples iterates route.methods, typed set[str] | None An APIRoute always has methods; handle None explicitly.
app/app.py app.openapi = ... "cannot assign to a method" A deliberate FastAPI override. A targeted # type: ignore[method-assign] with a comment is correct here.
app/app.py, authenticate route fields: list[ProfileField] | None passed where list[str] | None is expected Annotate PESUAcademy.authenticate with list[ProfileField] | None.
app/app.py, authenticate route authentication_result is reused for a dict and then a ResponseModel (two errors) Use separate names.
app/docs/base.py bare dict (two errors) Give the type arguments.

None of these is a runtime bug today. The one this issue first found, an empty CSRF token, went away with the CSRF flow in 5.0.0. They are the kind of gap where the next change hides one.

Proposed change

  1. Add mypy to the dev dependency group, and configure it in pyproject.toml:
    • [tool.mypy] with strict = true, plugins = ["pydantic.mypy"], and files = ["app"];
    • start with app/ only, and add scripts/ and tests/ in later PRs.
  2. Fix every error. Prefer real fixes over # type: ignore. Every ignore must name the error code and have a comment explaining it.
  3. Run it:
    • as a local pre-commit hook (language: system, entry: mypy, like the pytest hook), so it uses the locked version;
    • in the Package checks job of ci_checks.yml, as a step after ruff.
  4. Document it in CONTRIBUTING.md's "Linting & Formatting" section.

House rules for workflow changes:

  • Keep workflow comments to short one-liners, matching the existing files, and put the reasoning in the PR description.
  • Every PR check runs from .github/workflows/ci_checks.yml. The only required status check on dev is Greenlight - CI checks, which fails if any job it needs failed. Add a new job to its needs list and to CHECK_RESULTS, or the job won't block a merge, and don't rename the Greenlight job, or the required check never reports.
  • Image builds and Render deploys run through shared workflows in pesu-dev/actions (build_push_image.yml and deploy_render.yml, used at @v1). A change to them is a PR to that repository, followed by moving its v1 tag.
  • astral-sh/setup-uv publishes no floating major tag, so pin an exact version (CI uses @v9.0.0) or a commit SHA.
  • ci_checks.yml runs on pull requests, so test a workflow change by opening a pull request inside your fork (from your branch to your fork's dev), and link the green run in your PR.

Acceptance criteria

  • uv run mypy passes with strict = true on app/
  • Every finding in the table is fixed
  • mypy runs in pre-commit and in CI's Package checks job
  • No unexplained # type: ignore

How to contribute

  • Wait until you're assigned. Comment to ask for this issue, then wait for a maintainer to assign it to you before writing any code. PRs for unassigned issues are closed without review.
  • Read CONTRIBUTING.md first. It covers forking, setting up with uv, and running the tests.
  • Branch from dev in your fork, and open the PR against dev with a Conventional Commit title and Closes #212 in the description.
  • Bump the minor version in pyproject.toml and run uv lock (CI checks this). uv run pre-commit run --all-files must pass, and coverage must stay at 100%.
  • Update the README, app/docs/ and comments in the same PR as the behaviour they describe.
  • Never log, print, store or echo a password or token, including in tests, PR descriptions and screenshots.
Lingua principale
Python
Stelle
22
Fork
29
Merge medio
1g 3h
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pesu-dev/auth

Tutte le issue di pesu-dev/auth

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.