Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

FunctionInputOutputTypeChecker rejects correct values for fixed-length tuple annotations (tuple[int, str])

Open Beginner friendly
  • Is something wrong?
#1,749 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start in htypes.check_instance, where the issue says list, set, and tuple share a branch, and compare its tuple handling with check_input_type, which already handles fixed-length tuples. Add coverage for element types, tuple length, empty tuple annotations, and tuple[X, ...]; the issue describes the expected pass and fail cases. The change is done when those cases pass, including the adapter and driver behavior.

Written by the indexing model from the issue text.

Description

With lifecycle.default.FunctionInputOutputTypeChecker enabled, a node annotated with a fixed-length tuple such as tuple[int, str] fails on a correct value, and a wrong-length tuple passes.

Current behavior

htypes.check_instance handles list, set and tuple in one branch and checks every element against the first type argument (element_type = element_type[0]). For tuple[int, str] that means "a" is checked against int.

  • check_instance((1, "a"), tuple[int, str]) returns False
  • check_instance((1,), tuple[int, str]) returns True
  • check_instance((1,), tuple[()]) raises IndexError: tuple index out of range

tuple[int, ...] is handled correctly. check_input_type already handles fixed-length tuples (#1550); check_instance does not.

Stack Traces

  File "hamilton/lifecycle/default.py", line 533, in run_after_node_execution
    raise TypeError(
TypeError: Node pair returned a result of type <class 'tuple'>, expected tuple[int, str]

Steps to replicate behavior

from hamilton import ad_hoc_utils, driver
from hamilton.lifecycle import default

def pair() -> tuple[int, str]:
    return 1, "a"

def describe(pair: tuple[int, str]) -> str:
    return f"{pair[0]}-{pair[1]}"

dr = (
    driver.Builder()
    .with_modules(ad_hoc_utils.create_temporary_module(pair, describe))
    .with_adapters(default.FunctionInputOutputTypeChecker())
    .build()
)
dr.execute(["describe"])  # TypeError: Node pair returned a result of type <class 'tuple'>, expected tuple[int, str]

Without the adapter it returns {'describe': '1-a'}.

Library & System Information

Apache Hamilton main @ fa786eae, Python 3.12, macOS.

Expected behavior

Fixed-length tuples are checked position by position, including the length: (1, "a") passes for tuple[int, str], while (1,) and ("a", 1) are rejected. tuple[X, ...] keeps checking every element against X.

Additional context

The fix is a small extra branch in check_instance for origin is tuple when the type isn't tuple[X, ...]. It doesn't overlap with #1739 (other generics in the same function). I have it with regression tests (unit tests plus a driver test with the adapter) and would like to open a PR for it.

Disclosure: found, reproduced and the draft fix tested locally with the help of an AI coding agent (Claude Code); reviewed before filing.

Dominant language
Jupyter Notebook
Stars
2.6k
Forks
218
Avg merge
2d 13h
Merged PRs (30d)
18

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/hamilton

All issues in apache/hamilton

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.