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

WIP: Add converters from typed-settings #820

Closed
wants to merge 3 commits into from
Closed

WIP: Add converters from typed-settings #820

wants to merge 3 commits into from

Conversation

sscherfke
Copy link
Contributor

See: #813

Pull Request Check List

This is just a friendly reminder about the most common mistakes. Please make sure that you tick all boxes. But please read our contribution guide at least once, it will save you unnecessary review cycles!

If an item doesn't apply to your pull request, check it anyway to make it apparent that there's nothing left to do. If your pull request is a documentation fix or a trivial typo, feel free to delete the whole thing.

  • Added tests for changed code.
  • 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.
  • Updated documentation for changed code.
    • New functions/classes have to be added to docs/api.rst by hand.
    • Changes to the signature of @attr.s() have to be added by hand too.
    • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives. Find the appropriate next version in our __init__.py file.
  • Documentation in .rst files is written using semantic newlines.
  • Changes (and possible deprecations) have news fragments in changelog.d.

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!

@sscherfke
Copy link
Contributor Author

Typing can be quite tricky. I’d be grateful if anyone could improve the type hints in converters.pyi. :-)

@Tinche
Copy link
Member

Tinche commented Jun 6, 2021

Heh, I'm just finishing up a blog post about how attrs+cattrs is better than Pydantic since these kinds of type-altering converters don't belong on the models themselves. A small taste of the post: what if you want two code paths for converting datetimes, one for ISO 8601 and one for the unix timestamps? Also paying the price for those code paths in your code (i.e. when not loading from json or whatever) is silly.

Well, at least in attrs they would be opt-in if we merge this, instead of just there forever like in Pydantic (I'm aware of Pydantic ORM mode).

@sscherfke
Copy link
Contributor Author

Yes, I see your point. But these converters (and maybe eventually the auto-convert hook) are purely optional and make writing simple API clients or loading data from JSON a lot easier. And you don't need to install the additional cattr packages for these simple cases.

@sscherfke
Copy link
Contributor Author

Closing this in favor of #830

@sscherfke sscherfke closed this Aug 6, 2021
@sscherfke sscherfke deleted the converters branch August 6, 2021 18:38
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.

None yet

3 participants