Django channels stubs

[huynguyengl99]

Stubs package for Django channels

Ref:

• Stubs package for Django Channels #14020

[huynguyengl99]

Hi @sobolevn,
I’ve created stubs to add type hint support for django-channels. Sorry for the tag, but if you have some time, could you please take a look and share any feedback or suggestions? I’d really appreciate your input!

[sobolevn]

I have some concerns about adding django-channels to typeshed. I would like to discuss them in detail here:

1. Since django-stubs does not support pyright and other type checkers - what will be the result of adding these types here, where pyright and pytype are also included in the CI?
2. What about different django versions? Does django-channels have any difference between them? We (django-stubs) only support the latest django version
3. Does django-channels need any extra features? Would it benefit from a custom mypy plugin?

[Tatsh]

There is a very good example of usage of Channels here.

I have some concerns about adding django-channels to typeshed. I would like to discuss them in detail here:

1. Since django-stubs does not support pyright and other type checkers - what will be the result of adding these types here, where pyright and pytype are also included in the CI?

From the way I've been using Channels, it will not pull in anything that will not work properly with Pyright such as an app's models.

2. What about different django versions? Does django-channels have any difference between them? We (django-stubs) only support the latest django version

They only check for Django>=4.2.

3. Does django-channels need any extra features? Would it benefit from a custom mypy plugin?

I do not believe so.

It is a somewhat active project so I think the typing should go in the project itself rather than here.

[sobolevn]

(not a full review)

[huynguyengl99]

@sobolevn

1. Since django-stubs does not support pyright and other type checkers — what will be the result of adding these types here, where pyright and pytype are also included in the CI?

I agree with @Tatsh, and I am creating an extension package for Channels. It looks like django-stubs partially supports Pyright, rather than having no support at all. So for the Channels stubs themselves, it should work fine because they don’t currently require the mypy plugin — meaning the other type checkers should handle it well.

2. What about different Django versions? Does django-channels have any differences between them? We (django-stubs) only support the latest Django version.

As I mentioned in your code feedback, I think there’s no significant difference between versions because Channels only relies on some stable Django imports. I will check and aim to support at least Django 4.2 if possible. For that, I think requiring django-stubs >=4.2 would be the best for compatibility. Is it right or should I just use the latest 5.2 for django stubs?

3. Does django-channels need any extra features? Would it benefit from a custom mypy plugin?

I think not. However, one useful addition to the main django-channels package could be something like ChannelScope, which defines additional keys that can be accessed. This way, if users want to extend the scope, they can extend that type and annotate it in their code.

@Tatsh, I used to think about adding type annotations directly to Channels instead of creating a stubs package, but there’s a comment from carltongibson mentioning that type hints have been rejected in Django. So, Channels will likely follow that approach — that’s the main reason for creating the stubs.

[sobolevn]

(not a full review)

[huynguyengl99]

Hi @sobolevn, I have updated the code following your suggestions and left a small question related to the dispatch function in my above comment. I hope you can have a quick look at that to see if it's okay or not.

[huynguyengl99]

Hi @sobolevn and @carltongibson, after implementing the fixes based on your feedback, do you think the code is ready to merge now, or should it be reviewed more carefully?

[huynguyengl99]

Hi @srittau, @brianschubert,
I’ve updated the code based on your suggestions — including adding comments, updating default values, and making a few minor improvements. When you have a moment, could you take a look at the latest commit and let me know if you have any feedback or concerns? Thanks so much!

[srittau]

Thanks! A few more remarks below, mostly around non-documented Anys.

[huynguyengl99]

Hi @srittau, all of your feedback has been addressed. When you have time, could you please take another look? Thank you very much!

[srittau]

Thanks and sorry for the delay!

[huynguyengl99]

Hi @srittau, thank you for the approval! I just have one last question — should I update this branch by merging the main branch into it, rebasing it onto the latest main, or just leave it as is and merge it directly?

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

strawberry (https://github.com/strawberry-graphql/strawberry)
- strawberry/channels/handlers/base.py:14: error: Cannot find implementation or library stub for module named "channels.consumer"  [import-not-found]
- strawberry/channels/handlers/base.py:15: error: Cannot find implementation or library stub for module named "channels.generic.websocket"  [import-not-found]
+ ...typeshed_to_test/stdlib/builtins.pyi:137: note: "__init_subclass__" of "object" defined here
+ strawberry/channels/handlers/base.py:57: error: Incompatible types in assignment (expression has type "ChannelsLayer | None", base class "AsyncConsumer" defined the type as "BaseChannelLayer")  [assignment]
+ strawberry/channels/handlers/base.py:66: error: Argument 1 of "dispatch" is incompatible with supertype "AsyncConsumer"; supertype defines the argument type as "dict[str, Any]"  [override]
+ strawberry/channels/handlers/base.py:66: note: This violates the Liskov substitution principle
+ strawberry/channels/handlers/base.py:66: note: See https://mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides
+ strawberry/channels/handlers/base.py:77: error: Argument 1 to "dispatch" of "AsyncConsumer" has incompatible type "ChannelsMessage"; expected "dict[str, Any]"  [arg-type]
- strawberry/channels/testing.py:13: error: Cannot find implementation or library stub for module named "channels.testing.websocket"  [import-not-found]
+ strawberry/channels/handlers/ws_handler.py:133: error: Argument 1 to "run" of "AsyncBaseHTTPView" has incompatible type "GraphQLWSConsumer[Context, RootValue]"; expected "GraphQLWSConsumer[None, None]"  [arg-type]
- strawberry/channels/handlers/http_handler.py:22: error: Cannot find implementation or library stub for module named "channels.db"  [import-not-found]
- strawberry/channels/handlers/http_handler.py:23: error: Cannot find implementation or library stub for module named "channels.generic.http"  [import-not-found]
+ strawberry/channels/handlers/http_handler.py:200: error: "BaseGraphQLHTTPConsumer" has no attribute "run"  [attr-defined]
+ strawberry/channels/handlers/http_handler.py:207: error: Argument "headers" to "send_headers" of "AsyncHttpConsumer" has incompatible type "dict[bytes, bytes]"; expected "Iterable[tuple[bytes, bytes]] | None"  [arg-type]
+ strawberry/channels/handlers/http_handler.py:360: error: Return type "Coroutine[Any, Any, ChannelsResponse | MultipartChannelsResponse]" of "run" incompatible with return type "ChannelsResponse" in supertype "SyncBaseHTTPView"  [override]
- strawberry/channels/router.py:14: error: Cannot find implementation or library stub for module named "channels.routing"  [import-not-found]

[srittau]

We always squash merge. For future reference: Please don't force push during development, that makes reviewing harder.