Skip to content

added explicit typing to all async pipeline commands #8325

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

Merged
merged 11 commits into from
Jul 19, 2022

Conversation

bentheiii
Copy link
Contributor

No description provided.

@github-actions

This comment has been minimized.

@@ -169,7 +170,7 @@ PSWorkerThreadExcHandlerT: TypeAlias = PubsubWorkerExceptionHandler | AsyncPubsu
CommandT: TypeAlias = tuple[tuple[str | bytes, ...], Mapping[str, Any]]
CommandStackT: TypeAlias = list[CommandT]

class Pipeline(Redis[_StrType], Generic[_StrType]):
class Pipeline(Generic[_StrType]):
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not a full review yet, but since Pipeline derives from Redis at runtime, we should keep that relationship. This unfortunately means that we will need lots of # type: ignore[override]. See also redis.client.Pipeline.

@github-actions

This comment has been minimized.

1 similar comment
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@bentheiii bentheiii requested a review from srittau July 19, 2022 08:44
@github-actions

This comment has been minimized.

Copy link
Collaborator

@srittau srittau left a comment

Choose a reason for hiding this comment

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

Thanks! While I didn't verify every argument type, things are looking good. There's only one thing I noticed: Could you replace instances of Any | None with Incomplete | None? _typeshed.Incomplete is a fairly new alias for Any (so it's not used much yet in typeshed) that's supposed to mark types that can be improved as opposed to Any, which is used for types where we can't do better within the capabilities of the type system.

@github-actions

This comment has been minimized.

Comment on lines +22 to +27
redis.asyncio.client.Pipeline.command_info
redis.asyncio.client.Pipeline.debug_segfault
redis.asyncio.client.Pipeline.memory_doctor
redis.asyncio.client.Pipeline.memory_help
redis.asyncio.client.Pipeline.script_debug
redis.asyncio.client.Pipeline.shutdown
Copy link
Member

@AlexWaygood AlexWaygood Jul 19, 2022

Choose a reason for hiding this comment

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

These allowlist entries are all because the methods in question are async def methods at runtime but not async def methods in the stub.

  1. Are you sure it's correct to have them as not being async def in the stub?
  2. If you are sure, can you put these allowlist entries in a separate section, and add a comment explaining why we're ignoring the stubtest errors? I don't think these entries belong in the "unclear problems" section, since we know why stubtest is complaining here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @AlexWaygood

I'm sure in the sense that it doesn't really matter, in principle this function should be syncronous in the pipeline, just like all other redis commands. In practice, because the functions are defined as async in the superclass unlike most commands (I can't really tell why), then any attempt to use these commands in a pipeline would result in a bug.

I will place these entreis in their own section

@github-actions
Copy link
Contributor

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@AlexWaygood AlexWaygood dismissed their stale review July 19, 2022 12:53

Not sure I really understand what's going on here, but I'm happy for @srittau to merge if he's happy!

@bentheiii bentheiii requested a review from srittau July 19, 2022 12:58
Copy link
Collaborator

@srittau srittau left a comment

Choose a reason for hiding this comment

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

LGTM, if we need to tweak the stubs later, we can always do so.

@srittau srittau merged commit 25e7474 into python:master Jul 19, 2022
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