Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Comments

Fixoptional validator to accept tuples of len > 1#1496

Open
finite-state-machine wants to merge 10 commits intopython-attrs:mainfrom
finite-state-machine:FixOptionalValidatorAnnotation
Open

Fixoptional validator to accept tuples of len > 1#1496
finite-state-machine wants to merge 10 commits intopython-attrs:mainfrom
finite-state-machine:FixOptionalValidatorAnnotation

Conversation

@finite-state-machine
Copy link
Contributor

@finite-state-machinefinite-state-machine commentedJan 4, 2026
edited
Loading

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.)

Theoptional validator (attrs.validators.optional) should accept anytuple of validators, just as it accepts anylist of validators. It looks like the peculiar type annotation syntax for variable-lengthtuples (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

  • Donot open pull requests from yourmain 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, butyou have been warned.
  • (N/A) Addedtests 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 filetyping-examples/baseline.py or, if necessary,typing-examples/mypy.py.
    • (N/A) If they've been added toattr/__init__.pyi, they'vealso been re-imported inattrs/__init__.pyi.
  • (N/A) Updateddocumentation for changed code.
    • New functions/classes have to be added todocs/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 appropriateversionadded,versionchanged, ordeprecateddirectives.
      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 bothattrs.define() andattr.s(), you have to add version directives to both.
  • (N/A) Documentation in.rst and.md files is written usingsemantic newlines.
  • Changes (and possible deprecations) have news fragments inchangelog.d.
  • Consider grantingpush permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

@finite-state-machine
Copy link
ContributorAuthor

finite-state-machine commentedJan 4, 2026
edited
Loading

The "ty" type checker seems to be doing a poor job of inferring the type of thege validator: it thinks the specialization isLiteral[0] rather thanint. To me, this feels like "ty" bug which would require an uglycast(int, 0) orint(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
Copy link
ContributorAuthor

finite-state-machine commentedJan 4, 2026
edited
Loading

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.

@finite-state-machinefinite-state-machine marked this pull request as ready for reviewJanuary 4, 2026 00:45
@hynek
Copy link
Member

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 forhttps://play.ty.dev/ so we could report it to them?

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@finite-state-machine@hynek

[8]ページ先頭

©2009-2026 Movatter.jp