Skip to content

Conversation

@ananya4khandelwal
Copy link

Pull Request Template: Failing Tests for Tuple/List Handling Bugs


PR Title

test: Add failing tests exposing bugs in tuple/list option handling

Description

This PR adds a comprehensive test suite that exposes several bugs and inconsistencies in how Typer handles multiple values, particularly with tuple and list options.

Why This PR?

Per the project guidelines, I'm submitting failing tests first to:

  1. Document the bugs clearly before attempting fixes
  2. Get maintainer confirmation that these are indeed bugs worth fixing
  3. Provide regression tests for future fixes
  4. Help other contributors understand the issues

🐛 Bugs Exposed by These Tests

Bug #1: Multiple Value Options Return tuple Instead of list

Test Class: TestListVsTupleInconsistency

When using List[str] type hint with multiple=True, Typer returns a tuple instead of a list.

def main(names: List[str] = typer.Option([], multiple=True)):
    print(type(names))  # Prints: <class 'tuple'> ❌ Should be: <class 'list'>

Impact:

  • Violates type hints and type safety
  • Users cannot use list methods like .append()
  • Contradicts documentation

Related:

  • Existing GitHub issue about tuple vs list behavior
  • User confusion in discussions

Bug #2: Tuple Options with None Defaults Don't Handle Missing Values Properly

Test Class: TestTupleOptionNoneDefaults

When tuple options have (None, None, None) as default, validation and None-handling is inconsistent.

def main(user: tuple[str, int, bool] = typer.Option((None, None, None))):
    username, coins, is_wizard = user
    # How are the None values handled?

Impact:

  • Confusing user experience
  • Unclear error messages
  • Difficult to create "optional" tuple options

Related to: docs_src/multiple_values/options_with_multiple_values/tutorial001_py39.py


Bug #3: List[Tuple[str, str]] Not Supported

Test Class: TestEdgeCases

Despite Click supporting nested tuples, Typer raises AssertionError for List[Tuple[...]].

def main(pairs: List[tuple[str, str]] = typer.Option([])):
    # AssertionError: "List types with complex sub-types are not currently supported"

Impact:

  • Limits advanced use cases
  • Forces workarounds with callbacks

📁 Files Added

tests/test_typer_bugs.py

Comprehensive test file with:

  • 5 test classes covering different bug categories
  • 12+ individual test cases
  • Uses @pytest.mark.xfail for known failures
  • Well-documented with expected vs actual behavior
  • Ready for regression testing once bugs are fixed

🧪 Test Structure

class TestListVsTupleInconsistency:
    """Tests for Bug #1"""
    
    @pytest.mark.xfail(reason="Known bug: returns tuple instead of list")
    def test_list_option_should_return_list_not_tuple(self):
        # Test that fails because of the bug
        pass

class TestTupleOptionNoneDefaults:
    """Tests for Bug #2"""
    
    def test_tuple_option_none_default_should_handle_missing_gracefully(self):
        # Documents current inconsistent behavior
        pass

✅ Testing

How to Run These Tests

# Install Typer in development mode
cd typer
pip install -e .

# Run the new bug tests
pytest tests/test_typer_bugs.py -v

# Run specific test class
pytest tests/test_typer_bugs.py::TestListVsTupleInconsistency -v

# Include xfail tests
pytest tests/test_typer_bugs.py -v --runxfail

Current Test Results

  • Expected: Most tests will fail (that's the point!)
  • ⚠️ Tests marked with @pytest.mark.xfail document known bugs
  • 📋 Tests marked with @pytest.mark.skip need dev install

🎯 Next Steps (After This PR)

If maintainers confirm these are bugs worth fixing:

  1. Follow-up PR Documentation full review  #1: Fix Bug [FEATURE] Handling Path / File arguments easily #2 (Tuple None handling)

    • Easiest to fix
    • Clear user benefit
    • Low risk
  2. Follow-up PR [FEATURE] Handling Path / File arguments easily #2: Fix Bug Documentation full review  #1 (List vs Tuple)

    • More complex
    • Need to ensure backward compatibility
    • High user impact
  3. Follow-up PR Auto-document command with docstrings #3: Enhancement for Bug Auto-document command with docstrings #3 (Nested types)

    • Optional enhancement
    • Requires design decision

📝 Notes

  • No production code changed - Only test additions
  • Zero risk of breaking changes - Tests can be merged safely
  • Good documentation - Each test explains expected vs actual behavior
  • Follows pytest best practices - Uses xfail, skip, fixtures properly

🔗 Related Issues

  • Link to GitHub issue about tuple/list inconsistency (if exists)
  • Link to discussions about List[Tuple[...]] support

✨ Contribution Checklist

  • Tests added for discovered bugs
  • Tests are well-documented with docstrings
  • Tests use appropriate pytest markers (xfail, skip)
  • No changes to production code
  • Follows existing test patterns in the repo
  • Ready for review

💬 Questions for Maintainers

  1. Are these confirmed bugs or intended behavior?
  2. Priority order for fixing these bugs?
  3. Backward compatibility concerns for Bug Documentation full review  #1 (list vs tuple)?
  4. Interest in Bug Auto-document command with docstrings #3 enhancement (nested types)?

Thank you for reviewing! I'm happy to:

  • Add more test cases
  • Adjust test structure
  • Work on fixes in follow-up PRs
  • Address any feedback

@github-actions github-actions bot added the docs Improvements or additions to documentation label Feb 8, 2026
@github-actions
Copy link
Contributor

github-actions bot commented Feb 8, 2026

📝 Docs preview

Last commit 36c0529 at: https://5f5b417b.typertiangolo.pages.dev

@github-actions
Copy link
Contributor

github-actions bot commented Feb 9, 2026

This was marked as potentially AI generated and will be closed now. If this is an error, please provide additional details, make sure to read the docs about contributing and AI.

@github-actions github-actions bot closed this Feb 9, 2026
Copy link
Member

@svlandeg svlandeg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also see my comment on an earlier PR: #1517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Improvements or additions to documentation maybe-ai

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants