Fix optional validator to accept tuples of len > 1

[finite-state-machine]

IMPORTANT

The pre-commit hooks are reverting my work-around for the "ty" issue, even with an attempted work around for the pre-commit issue. Rather than adding yet another work-around, I'm going to see what the maintainers suggest.

Summary

Replaces #1495 (I renamed my branch, which closed the draft PR.)

The optional validator (attrs.validators.optional) should accept any tuple of validators, just as it accepts any list of validators. It looks like the peculiar type annotation syntax for variable-length tuples (tuple[<type>, ...]) was overlooked, and the exactly-one-element form (tuple[<type>]) was inadvertently used instead.

The proposed change corrects the annotation.

Pull Request Check List

• Do not open pull requests from your main branch – use a separate branch!
  • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
  • This is not a pre-requisite for your pull request to be accepted, but you have been warned.
• (N/A) Added tests for changed code.
  Our CI fails if coverage is not 100%.
• Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
  • ...and used in the stub test file typing-examples/baseline.py or, if necessary, typing-examples/mypy.py.
  • (N/A) If they've been added to attr/__init__.pyi, they've also been re-imported in attrs/__init__.pyi.
• (N/A) Updated documentation for changed code.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changes to the signatures of @attr.s() and @attrs.define() have to be added by hand too.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    The next version is the second number in the current release + 1.
    The first number represents the current year.
    So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0.
    If the next version is the first in the new year, it'll be 23.1.0.
    • If something changed that affects both attrs.define() and attr.s(), you have to add version directives to both.
• (N/A) Documentation in .rst and .md files is written using semantic newlines.
• Changes (and possible deprecations) have news fragments in changelog.d.
• Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

[finite-state-machine]

The "ty" type checker seems to be doing a poor job of inferring the type of the ge validator: it thinks the specialization is Literal[0] rather than int. To me, this feels like "ty" bug which would require an ugly cast(int, 0) or int(0) to work around, but I also understand the automated testing needs to pass (when nothing's wrong), or it's not useful.

https://github.com/python-attrs/attrs/actions/runs/20684969634/job/59384179969?pr=1496

What would you suggest, @Tinche?

[finite-state-machine]

IMPORTANT

I've tried to work-around the "ty" issue, but the pre-commit hooks have "helpfully" undone my fix (my change: c1129cc, "helpful" hook's change: 5b41382) [edit:] and again, despite [skip pre-commit.ci] in the commit message.

[hynek]

If the type hints are correct, there should be no workarounds to appease ty, but a # ty: ignore[invalid-argument-type]

Would it be possible to create a minimal reproducer for https://play.ty.dev/ so we could report it to them?