DRAFT Add flags to generate only sync or only async stubs #694

WouldYouKindly · 2025-11-25T14:51:47Z

This PR adds flags to generate only sync or only async stubs.

aidandj · 2025-11-25T14:55:45Z

What is the need for this with the last round of changes that generates both?

WouldYouKindly · 2025-11-25T15:01:08Z

What is the need for this with the last round of changes that generates both?

Two things:

On our codebase, running mypy with generated stubs results in OOM - mypy 1.18.2 consumes 20GB+ of RAM. Probably because of too many generics.
It's nice to be able to copy the types from the generated stubs to the implementations. Sync+Async stubs are quite unwieldy, and I assume most people wouldn't want to see them in their code.

aidandj · 2025-11-25T15:06:13Z

Sounds good, I'll review later today.

Can you update the readme documenting the option, and fix the tests.

aidandj · 2025-11-25T15:11:08Z

@nipunn1313 I know we just talked about expanding options too much, but I've definitely wanted to be able to copy the stubs straight across, and this allows a bit more configuration.

Yesterday I was using ts-proto which has about a billion options, and with documentation it was fine.

I think as long as this has full tests for each option, I'm not opposed to it.

nipunn1313 · 2025-11-25T21:32:28Z

This one seems like a reasonable one to do. What is the command line flags you are envisioning and what are the defaults that you envision?

I think onus is high here to have sane defaults (maybe async-only?) - and then have a flag to flip to the other options.

Re: memory usage - I think it may be (separately) worth for you to consider profiling to figure out how to resolve that issue to make the generator more efficient. This feels like it will only be a bandaid for an OOM issue.

aidandj · 2025-11-25T21:35:33Z

I think the default should probably be both still. I think it's a better general default for normal first-time users, and also won't be a breaking change.

aidandj · 2025-11-25T21:35:43Z

I think the default should probably be both still. I think it's a better general default for normal first-time users, and also won't be a breaking change.

aidandj · 2025-11-25T21:35:44Z

I think the default should probably be both still. I think it's a better general default for normal first-time users, and also won't be a breaking change.

WouldYouKindly · 2025-11-26T14:41:18Z

This one seems like a reasonable one to do. What is the command line flags you are envisioning and what are the defaults that you envision?

I think onus is high here to have sane defaults (maybe async-only?) - and then have a flag to flip to the other options.

Re: memory usage - I think it may be (separately) worth for you to consider profiling to figure out how to resolve that issue to make the generator more efficient. This feels like it will only be a bandaid for an OOM issue.

Currently the flags are sync_only/async_only. I agree with Aidan that default should be both - I have no idea if more people need sync or async stubs.

w.r.t. memory usage, I don't think it will be very easy to profile mypy's memory usage, especially given that it has mypyc-compiled parts... I know that the issue is with stubs - as soon as I remove a stub from .pyi file, I stop getting OOM.

aidandj · 2025-11-26T14:58:55Z

This one seems like a reasonable one to do. What is the command line flags you are envisioning and what are the defaults that you envision?

I think onus is high here to have sane defaults (maybe async-only?) - and then have a flag to flip to the other options.

Re: memory usage - I think it may be (separately) worth for you to consider profiling to figure out how to resolve that issue to make the generator more efficient. This feels like it will only be a bandaid for an OOM issue.

Currently the flags are sync_only/async_only. I agree with Aidan that default should be both - I have no idea if more people need sync or async stubs.

w.r.t. memory usage, I don't think it will be very easy to profile mypy's memory usage, especially given that it has mypyc-compiled parts... I know that the issue is with stubs - as soon as I remove a stub from .pyi file, I stop getting OOM.

I've had really good luck with memray and profiling. I think this would be good data to have, Even if we go ahead with the sync/async only stub generation. I know I personally don't have a code base large enough to reproduce this. Maybe you could give us an estimate on the size of your code base?

aidandj · 2025-11-26T14:58:59Z

This one seems like a reasonable one to do. What is the command line flags you are envisioning and what are the defaults that you envision?

I think onus is high here to have sane defaults (maybe async-only?) - and then have a flag to flip to the other options.

Re: memory usage - I think it may be (separately) worth for you to consider profiling to figure out how to resolve that issue to make the generator more efficient. This feels like it will only be a bandaid for an OOM issue.

Currently the flags are sync_only/async_only. I agree with Aidan that default should be both - I have no idea if more people need sync or async stubs.

w.r.t. memory usage, I don't think it will be very easy to profile mypy's memory usage, especially given that it has mypyc-compiled parts... I know that the issue is with stubs - as soon as I remove a stub from .pyi file, I stop getting OOM.

I've had really good luck with memray and profiling. I think this would be good data to have, Even if we go ahead with the sync/async only stub generation. I know I personally don't have a code base large enough to reproduce this. Maybe you could give us an estimate on the size of your code base?

WouldYouKindly · 2025-11-26T17:53:47Z

@aidandj it's really not that big. It's also public: https://github.com/Couchers-org/couchers. Here are the protos: https://github.com/Couchers-org/couchers/tree/develop/app/proto

WouldYouKindly · 2025-11-26T18:52:49Z

@aidandj I will try to make a repro a bit later, and submit an issue at least. In the meantime, the tests are fixed and the docs are updated - ready to be reviewed

aidandj · 2025-11-26T18:56:06Z

Hoping to get to it today, otherwise after our holiday weekend

aidandj

Good start. Missing a few things.

Typed constructors.
Tests are incomplete
- Please add full tests for the stub usage, at least equivalent to the tests in the existing grpc_usage and async_grpc_usage
Incorrect folder names (I realize I started this pattern with the concrete folder, fixed in the below PR)

When I was testing, I made some changes, here is a PR into your current branch: WouldYouKindly#1

aidandj · 2025-11-26T20:29:36Z

mypy_protobuf/main.py

+    BOTH = "BOTH"
+
+    @classmethod
+    def from_parameter(cls, parameter: str) -> GRPCType:


handle error case if someone passes in both options, either error with invalid option, or set both. I'd lean towards error

aidandj · 2025-11-26T20:35:02Z

mypy_protobuf/main.py

-            with self._indent():
-                wl("'{}',", _build_typevar_name(service.name, method.name))
-                wl("{}[", self._callable_type(method, is_async=False))
+            # Write only a sync of an async version


Suggested change

# Write only a sync of an async version

# Write only a sync or an async version

aidandj · 2025-11-26T20:46:17Z

mypy_protobuf/main.py

-            self.write_self_types(service, True)
-            wl("]")
-            wl("")
+            if self.grpc_type == GRPCType.BOTH and self.grpc_type.supports_async:


Suggested change

if self.grpc_type == GRPCType.BOTH and self.grpc_type.supports_async:

if self.grpc_type.supports_async:

aidandj · 2025-11-26T20:50:27Z

mypy_protobuf/main.py

+            return server
+        elif aserver:
+            return aserver
+        raise RuntimeError(f"Impossible, {self.grpc_type=}")  # pragma: no cover


What is the purpose of the pragma comment here?

The logic feels a bit confusing here. What about:

server = self._import("grpc", "Server") aserver = self._import("grpc.aio", "Server") if self.grpc_type == BOTH: return f"{self._import('typing', 'Union')}[{server}, {aserver}]" elif self.grpc_type == ASYNC: return aserver elif self.grpc_type == SYNC: return server else: raise RuntimeError(f"Impossible, {self.grpc_type=}")

aidandj · 2025-11-26T21:30:57Z

test/generated_async_only/testproto/grpc/dummy_pb2_grpc.pyi

+    testproto.grpc.dummy_pb2.DummyRequest,
+    testproto.grpc.dummy_pb2.DummyReply,
+]
+class DummyServiceStub:


Missing typed constructor, in sync as well

def __init__(channel: grpc.aio.Channel)

aidandj · 2025-11-26T21:31:33Z

run_test.sh

    find proto/testproto/grpc -name "*.proto" -print0 | xargs -0 "$PROTOC" "${PROTOC_ARGS[@]}" --mypy_grpc_out=generate_concrete_servicer_stubs:test/generated-concrete

+    # Generate with sync_only stubs for testing
+    find proto/testproto/grpc -name "*.proto" -print0 | xargs -0 "$PROTOC" "${PROTOC_ARGS[@]}" --mypy_grpc_out=only_sync:test/generated-sync-only


generated_sync_only

aidandj · 2025-11-26T21:31:41Z

run_test.sh

+    find proto/testproto/grpc -name "*.proto" -print0 | xargs -0 "$PROTOC" "${PROTOC_ARGS[@]}" --mypy_grpc_out=only_sync:test/generated-sync-only
+
+    # Generate with async_only stubs for testing
+    find proto/testproto/grpc -name "*.proto" -print0 | xargs -0 "$PROTOC" "${PROTOC_ARGS[@]}" --mypy_grpc_out=only_async:test/generated-async-only


generated_async_only

Rename folders Update pyproject.toml so pyright works on test code for sync/async only Signed-off-by: Aidan Jensen <aidandj.github@gmail.com>

Signed-off-by: Aidan Jensen <aidandj.github@gmail.com>

aidandj · 2025-12-05T20:07:53Z

@WouldYouKindly is this still something you'd like to finish working on?

WouldYouKindly · 2025-12-09T17:07:44Z

@WouldYouKindly is this still something you'd like to finish working on?

Yes, absolutely. I will be a bit freer next week to finish this hopefully.

I think this is useful to have even if the OOM is fixed - I'd imagine most people want to have either sync or async, not both at the same time. Not having overloads also allows one to copy the types from the generated classes into their implementation.

aidandj · 2025-12-09T17:09:08Z

I agree. Let's get that other change fixed first and rebase on it. I'd like to get that one rolled out to unblock people who upgraded.

aidandj · 2025-12-09T17:09:09Z

I agree. Let's get that other change fixed first and rebase on it. I'd like to get that one rolled out to unblock people who upgraded.

WouldYouKindly changed the title ~~Add flags to generate only sync or only async stubs~~ DRAFT Add flags to generate only sync or only async stubs Nov 25, 2025

WouldYouKindly force-pushed the sync-async-only branch from 5554042 to 42e644c Compare November 25, 2025 14:54

WouldYouKindly force-pushed the sync-async-only branch from 12e88d6 to 746701b Compare November 26, 2025 14:56

WouldYouKindly force-pushed the sync-async-only branch from 746701b to 859cc1c Compare November 26, 2025 16:42

Add flags to generate only sync or only async stubs

d946d68

WouldYouKindly force-pushed the sync-async-only branch from 859cc1c to d946d68 Compare November 26, 2025 16:44

WouldYouKindly added 2 commits November 26, 2025 17:09

Specify type parameters for context in async grpc methods

9727cbf

Ignore pyright errors in sync/async only stubs

52e18dd

WouldYouKindly force-pushed the sync-async-only branch from 45ba768 to 52e18dd Compare November 26, 2025 17:21

Update readme with sync_only/async_only option

ddd9a2f

aidandj requested changes Nov 26, 2025

View reviewed changes

aidandj added 2 commits November 27, 2025 10:47

Start adding tests

28d2401

Rename folders Update pyproject.toml so pyright works on test code for sync/async only Signed-off-by: Aidan Jensen <aidandj.github@gmail.com>

add constructor typing

3298f4b

Signed-off-by: Aidan Jensen <aidandj.github@gmail.com>

WouldYouKindly force-pushed the sync-async-only branch 2 times, most recently from 4f7cebc to 2080d44 Compare November 27, 2025 11:47

run black

cb32bd6

WouldYouKindly force-pushed the sync-async-only branch from 2080d44 to cb32bd6 Compare November 27, 2025 11:54

isort: skip generated grpc files

c497b7d

WouldYouKindly force-pushed the sync-async-only branch from 1bb7e4c to c497b7d Compare November 27, 2025 13:31

Add init files to generated sync/async

82e6e75

aidandj mentioned this pull request Nov 30, 2025

Implement a new parameter to generate only async stubs #631

Closed

	# Write only a sync of an async version
	# Write only a sync or an async version

	if self.grpc_type == GRPCType.BOTH and self.grpc_type.supports_async:
	if self.grpc_type.supports_async:

DRAFT Add flags to generate only sync or only async stubs #694

Are you sure you want to change the base?

DRAFT Add flags to generate only sync or only async stubs #694

Uh oh!

Conversation

WouldYouKindly commented Nov 25, 2025

Uh oh!

aidandj commented Nov 25, 2025

Uh oh!

WouldYouKindly commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aidandj commented Nov 25, 2025

Uh oh!

aidandj commented Nov 25, 2025

Uh oh!

nipunn1313 commented Nov 25, 2025

Uh oh!

aidandj commented Nov 25, 2025

Uh oh!

aidandj commented Nov 25, 2025

Uh oh!

aidandj commented Nov 25, 2025

Uh oh!

WouldYouKindly commented Nov 26, 2025

Uh oh!

aidandj commented Nov 26, 2025

Uh oh!

aidandj commented Nov 26, 2025

Uh oh!

WouldYouKindly commented Nov 26, 2025

Uh oh!

WouldYouKindly commented Nov 26, 2025

Uh oh!

aidandj commented Nov 26, 2025

Uh oh!

aidandj left a comment

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

aidandj commented Dec 5, 2025

Uh oh!

WouldYouKindly commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aidandj commented Dec 9, 2025

Uh oh!

aidandj commented Dec 9, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

WouldYouKindly commented Nov 25, 2025 •

edited

Loading

WouldYouKindly commented Dec 9, 2025 •

edited

Loading