* Simplify black configuration to be closer to upstream defaults Avoid extra configuration by simply going with Black defaults. This allows removing some configuration options, thus simplifying the overall configuration. It also makes the code style closer to community conventions. As more projects adopt black formatting, more code will look like the black defaults. Further, the default 88 tends to create more readable lines, IMO. The black rationale is located at: https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length * Update tests/test_api_jws.py Co-authored-by: José Padilla <jpadilla@webapplicate.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Update tests/test_api_jws.py * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci Co-authored-by: José Padilla <jpadilla@webapplicate.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
ModuleNotFoundError was introduced in Python 3. It is raised when the module does not exist. On the other hand, ImportError is raised during any import failure. For example, a syntax error or other runtime error. Using ModuleNotFoundError means that errors unrelated to a missing package will be propagated to the user. PyJWT doesn't know how to handle these. This also allows more functions to always be available for import
The class PyJWT was previously a subclass of PyJWS. However, this combination does not follow the Liskov substitution principle. That is, using PyJWT in place of a PyJWS would not produce correct results or follow type contracts. While these classes look to share a common interface it doesn't go beyond the method names "encode" and "decode" and so is merely superficial. The classes have been split into two. PyJWT now uses composition instead of inheritance to achieve the desired behavior. Splitting the classes in this way allowed for precising the type interfaces. The complete parameter to .decode() has been removed. This argument was used to alter the return type of .decode(). Now, there are two different methods with more explicit return types and values. The new method name is .decode_complete(). This fills the previous role filled by .decode(..., complete=True). Closes #554, #396, #394 Co-authored-by: Sam Bull <git@sambull.org> Co-authored-by: Sam Bull <git@sambull.org>
No need to create a fixture with a nested function. This can be a simple utility function.
Follows upstream cryptography commit: https://github.com/pyca/cryptography/commit/5528a3182fdd6ed1c44c126d451a87bcf39e79de Since Python 3.2, this bytes to an int is a native feature.
Now that the project is Python 3 only, the boundaries between bytes and Unicode strings is more explicit. This allows removing several unnecessary force_bytes() and force_unicode() calls that handled differences between Python 2 and Python 3. All uses of force_unicode() have been removed. For values that are known to be bytes, use `.decode()` instead. For values are that known to be str, use `.encode()` instead. This strategy makes the type explicit and reduces a function call. Key handling continues to use force_bytes() to allow callers to pass either bytes or str. To help enforce bytes/str handling in the future, the `-b` option is passed to Python when testing. This option will emit a warning if bytes and str are improperly mixed together.