Repository navigation
Un-ignore the ty invalid-assignment rule (good first issue, part of #15187) #15199
Description
Feature description
This is a bite-sized, self-contained slice of the ty gradual-typing baseline tracked in #15187 — un-ignoring the invalid-assignment rule.
Right now [tool.ty] in pyproject.toml carries rules.invalid-assignment = "ignore". On a synced 3.14 environment ty reports 23 invalid-assignment diagnostics across 9 files — all small, local fixes (mostly linked-list/tree node attributes typed Node | None where a plain Node or None is assigned, plus a couple of narrow subscript/annotation mismatches). No cross-file churn, so it makes a clean good-first-issue.
Current diagnostics
cellular_automata/conways_game_of_life.pycellular_automata/one_dimensional.pydata_structures/binary_tree/non_recursive_segment_tree.pydata_structures/heap/binomial_heap.pydata_structures/linked_list/doubly_linked_list.pydata_structures/linked_list/singly_linked_list.pyfractals/mandelbrot.pymachine_learning/automatic_differentiation.pynetworking_flow/minimum_cut.py
How to fix
uv sync, then runty check --exclude-scriptsand grep the output forinvalid-assignment.- Fix only these files — usually by widening/narrowing an attribute or variable annotation (e.g. typing a node's
next/previous/leftasNode | Noneat declaration), never by loosening runtime behaviour. Leave every other still-ignored rule untouched. - Delete the
rules.invalid-assignment = "ignore"line in[tool.ty]. - Confirm
tyreports zeroinvalid-assignmentdiagnostics, and that the existing test/doctest suite still passes, then open the PR.
Keep the PR scoped to this one rule so it stays easy to review. Happy to review when it's up.
Additional context
Part of #15187. Please comment to claim before starting so we don't get duplicate PRs.
Activity
kadubhumika commentedon Sep 6, 2026
Hi! I'd like to work on this issue. I'll focus only on fixing the
invalid-assignmentdiagnostics listed here and removing the corresponding ignore rule. Thanks!priya-sundaram-dev commentedon Sep 6, 2026
Welcome, @kadubhumika — that scope is exactly right. 🎉
A few pointers so your first PR lands smoothly:
invalid-assignmentdiagnostics. To see the current list on a synced env:uv run ty check(the ignore rule lives in[tool.ty]inpyproject.toml).Node | Nonewhere a plainNode(orNone) is assigned — usually the right fix is to make the annotation reflect reality (e.g.next: Node | None = None) rather than casting.invalid-assignmentdiagnostics are gone, delete therules.invalid-assignment = "ignore"line so the rule becomes active.ruff check/ruff formatbefore pushing.Ping me on the PR if
tyflags something ambiguous and I’m happy to help think it through. Looking forward to it!priya-sundaram-dev commentedon Sep 9, 2026
Thanks for jumping in, @franciscocastillo65 — looks like your comment got cut off mid-sentence ("...and
doubly_linked_list"), so I didn't quite catch the full question. Feel free to re-post the rest and I'll help.Two quick notes so effort doesn't collide:
invalid-assignmentsub-issue (Un-ignore thetyinvalid-assignmentrule (good first issue, part of #15187) #15199) with exactly the right scope, so the linked-list node files here are likely spoken for. Best to check with them before duplicating.tygradual-typing baseline (un-ignore rules; PEP 723 blocker astral-sh/ty#691) #15187 lists several othertyrules still to un-ignore (each carved as its own good-first-issue). Happy to point you at one that's unclaimed — just say the word.For the linked-list files specifically: the pattern is node attributes annotated
Node | Nonewhere a bareNode(orNone) gets assigned in__init__/insert; the fix is to make the annotation and the assignment agree, not to sprinkle# type: ignore.cclauss commentedon Sep 10, 2026
Closed in #15204