PyJWT 2.0.0: encode() return value is now str

[asottile]

https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.md#jwtencode-return-type

[github-actions]

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

+ homeassistant/auth/__init__.py:446: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ homeassistant/auth/__init__.py:446: error: Returning Any from function declared to return "str"  [no-any-return]
+ homeassistant/helpers/config_entry_oauth2_flow.py:509: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ homeassistant/helpers/config_entry_oauth2_flow.py:509: error: Returning Any from function declared to return "str"  [no-any-return]

+ alerta/models/token.py:120: error: "str" has no attribute "decode"; maybe "encode"?

+ zerver/tests/test_auth_backends.py:2079: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3905: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3918: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3928: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3956: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3968: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3981: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]
+ zerver/tests/test_auth_backends.py:3994: error: "str" has no attribute "decode"; maybe "encode"?  [attr-defined]

[asottile]

yeah, it broke my app too mypy_primer :P

[srittau]

pyjwt 2 now ships its own type hints, which take precedence over the ones shipped with typeshed. Which is great, since mypy marked the problem with encode() after upgrading in our code, too.

I think a better alternative is to keep the typings in typeshed compatible to pyjwt 1 and remove them completely in 6-12 months. (I opened #4856 for that.) This way we get the best of both worlds: Users upgrading to pyjwt 2 should get the type hints from the package itself, while users that haven't upgraded yet, still get proper pyjwt type hints. But I am curious what others think.

[asottile]

I'd rather get them from typeshed personally

[JelleZijlstra]

But type checkers will use stubs shipped with the package in preference to typeshed, so there doesn't seem much point in providing stubs for pyjwt 2 in typeshed if it comes with stubs already.

[asottile]

But type checkers will use stubs shipped with the package in preference to typeshed, so there doesn't seem much point in providing stubs for pyjwt 2 in typeshed if it comes with stubs already.

I prefer to install my type checkers separately as it means I can cache them. Installing pyjwt into that environment brings along a bunch of untyped bulk which makes it a bit annoying to use that way (ideally I'd just want the stubs, which is what typeshed gives me)

[srittau]

Unfortunately, you will need to install pyjwt anyway when we remove the stubs. Therefore, I prefer if we keep the old stubs for the reasons outlined above.

That said, I think your use case has merit, even if we don't support it at the moment. One idea for a project I had for a while is a "stub extractor" that just extracts the public API, including type annotations from a module. (Similar to what stubgen does.) This could help with that use case. If I find time ...

[asottile]

That said, I think your use case has merit, even if we don't support it at the moment.

isn't that kinda what typeshed already solves?

[srittau]

Ideally, typeshed wouldn't have any third-party packages, though. I've always seen it as a stopgap measure, until distributing typings with upstream packages (either inline or as separate stubs) becomes the standard. We will probably never reach that goal, but it is much more advantageous the have the types and the package closely coupled than to maintain them separately. (Despite the success of DefinitelyTyped in the typescript world.)

[asottile]

personally I see 561 as kind of a failure (not to mention the impossibility to distribute types for single-file packages) and ignoring the success of DefinitelyTyped is an unfortunate side-effect. typeshed may seem like a stopgap but 561 is not a solution. that I need to install 10MB of .so files (cryptography) to get stubs for pyjwt (a few KB) seems really really backward

[asottile]

should this be reopened / re-applied (#2491)

[srittau]

I don't think that #2491 changes anything. I still see typeshed as a repository for packages that don't ship their own stubs. This is also what our README file implies:

Third-party packages are generally removed from typeshed when one of the following criteria is met:

The upstream package ships a py.typed file for at least 6-12 months, or
the package does not support any of the Python versions supported by typeshed.

[asottile]

ah I see, I guess I misinterpreted #2491 as "typeshed becomes more like definitelytyped"