Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix type annotations for converter types, considering the Converter class #1373

Merged
merged 2 commits into from
Nov 27, 2024

Conversation

filbranden
Copy link
Contributor

Summary

A converter can either be a callable with a single argument or an instance of the Converter class, fix the type annotation to allow both cases everywhere _ConverterType is used

Also update field() and attr.ib() which are able to take a list or tuple of converters as an implicit pipe, add type annotations for that syntax

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.
  • Added tests for changed code.
    Our CI fails if coverage is not 100%.
  • N/A New features have been added to our Hypothesis testing strategy.
  • Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
    • ...and used in the stub test file tests/typing_example.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.
  • 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.

@filbranden
Copy link
Contributor Author

@hynek Would you kindly take a look whenever possible? Thanks!

@hynek hynek requested a review from Tinche November 25, 2024 07:54
…lass

Also consider that field() or attr.ib() takes a list or tuple of
converters as an implicit pipe, add type annotations for that syntax
Copy link
Member

@Tinche Tinche left a comment

Choose a reason for hiding this comment

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

LGTM from what I can follow

@hynek
Copy link
Member

hynek commented Nov 25, 2024

It looks to me like worthy a changelog entry because apparently converters are better supported now? 🤔

@filbranden
Copy link
Contributor Author

I believe Converters are already mentioned in the changelog for 24.1.0:

"It is now possible to wrap a converter into an attrs.Converter and get the current instance and/or the current field definition passed into the converter callable.

Note that this is not supported by any type checker, yet. #1267"

This just fixes some type annotations but I believe full type checker support would need some mypy changes (see commented out code) so not sure how much is worth mentioning in a changelog.

Having said that, feel free to add a note if you'd like 😃

@hynek hynek added this pull request to the merge queue Nov 27, 2024
Merged via the queue into python-attrs:main with commit 6c89173 Nov 27, 2024
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants