@jdufresne since you worked in some of the typing stuff recently, thoughts on this change?

Please note that there are even more types that some of the algorithms accept for the key argument.

Please note that there are even more types that some of the algorithms accept for the key argument.

I have no idea how to properly use them in the type annotations. Everything I've tried so far resulted some error by mypy.

This should work but would probably result in Union[Any, …] for every setup that doesn't use cryptography:

if MYPY:
    from cryptography.hazmat.primitives.asymmetric.ec import EllipticCurvePrivateKey

def prepare(key: Union[str, bytes, "EllipticCurvePrivateKey"]):
    pass

Personally I would be okay with just reverting to Any.

Please note that there are even more types that some of the algorithms accept for the key argument.

I have no idea how to properly use them in the type annotations. Everything I've tried so far resulted some error by mypy.

This should work but would probably result in Union[Any, …] for every setup that doesn't use cryptography:

if MYPY:
    from cryptography.hazmat.primitives.asymmetric.ec import EllipticCurvePrivateKey

def prepare(key: Union[str, bytes, "EllipticCurvePrivateKey"]):
    pass

I'm just checking to see if this relates to a change I was going to make with decode not accepting bytes, but the quoted Python should be expressed as the following:

# so KEY_TYPES is not needed at runtime and doesn't break because it's in the TYPE_CHECKING block.
# The constant could be define outside of the block and this future import would not be needed
from __future__ import annotations

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    try:
        from cryptography.hazmat.primitives.asymmetric.ec import EllipticCurvePrivateKey
        KEY_TYPES = Union[str, bytes, EllipticCurvePrivateKey]
    except ImportError:
        KEY_TYPES = Union[str, bytes]

def prepare(key: KEY_TYPES): ...

If you need this to be dynamic you could do the following:

_KEY_TYPES = [str, bytes]

# import 1
_KEY_TYPES.append(...)
# import 2
_KEY_TYPES.append(...)

KEY_TYPES = Union[tuple(_KEY_TYPES)]

This works because obj[one, two] is just passing (one, two) to obj.__getitem__ and as long as the type is a tuple not a list it will be the expected union.

It looks like this change is adjacent, but not the change I was looking to make. jwt should also be bytes | str for the decode functions and there may be other places it's been made too specific and only accepts str.

Your first example leads to Cannot assign multiple types to name "KeyType" without an explicit "Type[...]" annotation.

KEY_TYPES = Union[tuple(_KEY_TYPES)] → Invalid type alias: expression is not a valid type.

Also I don't think that something like _KEY_TYPES.append(…) could work at all as mypy doesn't import and/or run the code afaik. The same should be true for try-except.

Hmm good point. I hadn't completely thought about that and I was going off what I did (a while ago) without testing mypy. At this point I've changed the original type declaration and am playing with getting mypy running so I mainly came here for #605 (comment) but if you're not able to import or type against a concrete type I'm assuming you'd need to type with a protocol, but that only comes in Python 3.8.

One thing to call out that without cryptography being declared as typed or on typeshed (I haven't checked if it is) the import will fail in mypy and it will fall back to Any.

It looks like it's on typeshed but it might make sense to declare a common base for private keys https://github.com/python/typeshed/blob/master/stubs/cryptography/cryptography/hazmat/primitives/asymmetric/ec.pyi so that way protocols could be used before Python 3.8. It might be possible to type with Protocols keeping everything behind if typing.TYPE_CHECKING and using from __future__ import annotations to make sure that any use of Protocols is by mypy on Python 3.8 or greater.

Anyways, it does sound like it should just be typed as Any.

It looks like Protocol would be supported pre Python 3.8 via the typing_extensions, but not sure if declaring the protocol would be worth it vs just typing with Any

@jdufresne any suggestions on how to proceed?

I believe the consensus here would be to use Any. I know you're looking for input from @jdufresne / @jpadilla 's input, but looking at the call chain a call to j*.decode it will call j*.decode_complete which will likely use the key for:

Looking at the API closer it looks like algorithms are puggable here pyjwt.jwt.algorithms which means the API cannot be type safe. A algorithm will alg.prepare_key(self, key: T) -> U and alg.verify(self, msg: ?, key: U, sig: ?) -> bool and there's not a good way to type both of those.

@michael-k @jpadilla I think this PR should be changed to use Any, and moved forward.

At present, even the simple sample codes in the specification gives mypy warnings.

I've changed the type annotation to Any. @jdufresne could you review this PR again?

@michael-k One last thing: I think you should update https://github.com/jpadilla/pyjwt/blob/master/docs/api.rst.

bump - this is still an issue

I've rebased, but I don't seem to be able to re-open this PR.

Hi @michael-k, @auvipy,
I think this is still an issue, will this PR be re-opened?