Skip to content
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

Type hint plumbing functions #600

Closed
johnthagen opened this issue Nov 10, 2021 · 3 comments
Closed

Type hint plumbing functions #600

johnthagen opened this issue Nov 10, 2021 · 3 comments

Comments

@johnthagen
Copy link
Contributor

johnthagen commented Nov 10, 2021

Functions like plumbing.build_basic_type() are used by users that develop custom OpenApiSerializerFieldExtension and similar. If those users use mypy --strict to check their code, because some of drf-spectacular is typed and includes py.typed, the following mypy errors are thrown.

build_basic_type(OpenApiTypes.BYTE)
error: Call to untyped function "build_basic_type" in typed context

The types of this function need to be applied:

def build_basic_type(obj):

Ideally, all functions would be typed, but that could take some effort. plumbing seems to have a lot of functions that could be used by end users, so that could be a good place to focus.

@tfranzel
Copy link
Owner

I thought about that too. The project structure was intended to be roughly this:

  • The porcelain: utils.py types.py helpers.py (user facing)
  • The plumbing: plumbing.py (advanced user facing, people who write extensions)
  • The drainage: drainage.py, thought about calling it sewer.py but it seemed inappropriate (dragons ahead)

The distinction between plumbing and drainage primarily has to do with import cycle issues. According to above description, large parts of plumbing would belong into drainage, but it was tricky to plan that ahead properly. So I made sure the porcelain is properly typed, but of course --strict does not really care about the rest being only partially typed. In the beginning, plumbing was not intended to be user facing. It just kind of implicitly happened due to the extensions.

I'll try and add types when I have some spare time. The problem I see is that annotating has a cascading effect, and adding a 1-2 annotations led to our mypy going nuts. TypeGuard does help a lot though.

tfranzel added a commit that referenced this issue Dec 19, 2021
tfranzel added a commit that referenced this issue Dec 19, 2021
@tfranzel
Copy link
Owner

i had some time to play around with this. the strict flag is comprised of a whole bunch of flags. We can definitely improve the types, but some of the errors are so pedantic that i doubt we can fix them without a serious amount of jumping through burning hoops.

Half of the flags do pass though: #620

tfranzel added a commit that referenced this issue Feb 13, 2022
tfranzel added a commit that referenced this issue Feb 19, 2022
tfranzel added a commit that referenced this issue May 24, 2022
tfranzel added a commit that referenced this issue Jul 25, 2022
tfranzel added a commit that referenced this issue Dec 10, 2023
tfranzel added a commit that referenced this issue Dec 10, 2023
tfranzel added a commit that referenced this issue Dec 10, 2023
tfranzel added a commit that referenced this issue Dec 10, 2023
tfranzel added a commit that referenced this issue Dec 11, 2023
tfranzel added a commit that referenced this issue Dec 11, 2023
@johnthagen
Copy link
Contributor Author

My issues were fixed in

So I'll close this issue 🚀

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

No branches or pull requests

2 participants