Samuel Colvin

Closing this, as any new PR would need to be against https://github.com/pydantic/pydantic-settings

I'm sorry about the breaking change, it was not intentional, we should have thought about it more and been more careful. :pray: I don't think we can revert, the real...

PR welcome to update the changelog. I'm hoping to work full time on pydantic from next week once I get the first release of pydantic-core out and give arq some...

@PrettyWood do you have any suggestions? I'm really sorry about your pain but I'd rather not add a flag for one release, unless we really have to - the behavior...

I think that makes complete sense. I haven't started working (or thinking) on how we do exporting/dumping in v2/pydantic-core but imagine it'll be somewhat similar to validation where we have...

Yes, I think best to keep it open.

I wonder if this is what I need or if there's currently a work around for my (slightly simpler) case?: I'm building an async redis client with proper type hints....

I get that, but I need all the public methods to definitely return a coroutine. Otherwise, if it returned an optional coroutine, it would be extremely annoying to use. What...

Okay, so the simple answer is that what I'm trying to do isn't possible with python types right now. Thanks for helping - at least I can stop my search.

humm, but the example above under "Basic example" I would argue IS type-safe. All the methods which end `return self.execute(...)` return what `execute` returns - either a `Coroutine` or `None`....