-
Notifications
You must be signed in to change notification settings - Fork 14
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
new type hints i wrote seem to be wrong #162
Comments
Hey, Could you point to the place where we could return an awaitable? IIRC all the methods you changed the type hints didn't in fact return a functor, but instead they return an actual value. But I might be wrong. |
hi let's take the difference is in the client, as you know, methods in valkey-py all call execute_command if execute_command is sync, which is not very type checker and IDE friendly, but it is true |
As I mentioned here, In the example you provided in this issue, the function returns That's the reason I'm asking you to provide a concrete example. Correct me if I'm wrong, but the difference between sync and async clients in valkey-py is such that you're writing r.set("foo", "bar") in sync and await r.set("foo", "bar") in async. In that case, your type hints are correct. ret = r.set("foo", "bar")
await ret() |
ultimately this is what's happening valkey-py doesn't have async methods as public API, it has sync methods returning a coroutine object that you can await |
Yeah I understand that async function returns a coroutine. However, I'd like to reiterate that PEP 484 explicitly covers this. Have a look at this link. I'll quote the relevant part below: Coroutines introduced in PEP 492 are annotated with the same syntax as ordinary functions. However, the return type annotation corresponds to the type of await expression, not to the coroutine type: async def spam(ignored: int) -> str:
return 'spam'
async def foo() -> None:
bar = await spam(42) # type: str |
No this is not how PEP 484 or PEP 492 works for subclass overriding of synchronous methods. for async def type hints the return type is automatically upgraded to Coroutine[Any, Any, T], this does not mean an asynchronous method is allowed to override a synchronous one Use typing.reveal_type(foo) to see |
@graingert are you saying that our functions should have a type hint of |
I'm not sure what you're trying to say here:
|
I'm saying you should have two totally separate classes one with async methods and one with sync methods, and you shouldn't subclass the class with sync methods in your async class |
Could you point me to some PEP or anything that would state that? |
I meant for you to use reveal_type with a type checker |
https://mypy.readthedocs.io/en/latest/more_types.html#typing-async-await
|
This is the main point here. Our async client methods are meant to be And this doesn't show me why these statements are true:
If you could provide any resource that would state that I would really appreciate that. Brief googling didn't confirm this to me. |
And if you could show me what issue you're actually trying to solve (error or a type checker warning) I would also appreciate that |
Okay, so you're referring to the mypy error. I see. Thanks, I'll try to address it. |
Here's another example: https://mypy-play.net/?mypy=latest&python=3.12&gist=0e7063f1f9d9ee4e8ac6fe67f6a5d40d |
Yeah this one is understandable. However, I'd argue that in practice this will be never hit in valkey-py, since in order to get the "child" class you'll have to type from valkey.async.client import Valkey instead of from valkey.client import Valkey which is a strong hint everything going on there will be async. But I'll see what can be done with the typing. Thanks! |
This can be hit without getting the imports wrong because type checkers will assume the lowest common superclass in a bunch of cases, which will be your superclass with sync methods The Async client and the Sync client need to not share a common superclass (except object of course) |
hi @graingert so you're saying class A:
def a():
...
class B(A):
async def a():
... is wrong? but in this case and for writing async clients from scratch, wouldn't that make the source code double as big? |
Yep it's wrong, and fails when you type check it |
Thanks everyone for your input! We discussed this internally and decided to do the following:
|
Revert some typing commits Issue #162 revealed that the issues with typing in valkey-py are quite a bit deeper and require some rework of internal classes. The changes introduced in those commits turned out to not fix anything. At this point we need to publish the new beta because of accumulated fixes since 6.1.0b1. The typing system fixes will be introduced later. Closes #162
hi
so in the past few commits i have deleted
Awaitable
from the type hintsthe argumnet was that async methods don't return awaitable
which is right
but valkey-py methods aren't async, they are sync methods that could return an awaitable
so having
Awaitable
in the return types, while annoying, are correctthis problem was pointed out by
fix error
in python's discordthere is also the suggestion to have different methods for sync and async, or go fully sync
but that's not for me to decide
the question i have is, how would go about reverting the changes?
The text was updated successfully, but these errors were encountered: