* chore: improve typing of functions returning AnyCloudEvent
kafka.conversion.from_binary() and from_structured() return
AnyCloudEvent type var according to their event_type argument, but when
event_type is None, type checkers cannot infer the return type. We now
use an overload to declare that the return type is http.CloudEvent when
event_type is None.
Previously users had to explicitly annotate this type when calling
without event_type. This happens quite a lot in this repo's
test_kafka_conversions.py — this fixes quite a few type errors like:
> error: Need type annotation for "result" [var-annotated]
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: type v1.Event chainable Set*() methods
The v1.Event self-returning Set*() methods like SetData() were returning
BaseEvent, which doesn't declare the same Set* methods. As a result,
chaining more than one Set* method would make the return type unknown.
This was causing type errors in test_event_pipeline.py.
The Set*() methods now return the Self type.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: fix type errors in tests
mypy was failing with lots of type errors in test modules. I've not
annotated all fixtures, mostly fixed existing type errors.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: allow non-dict headers types in from_http()
from_http() conversion function was requiring its headers argument to
be a typing.Dict, which makes it incompatible with headers types of http
libraries, which support features like multiple values per key.
typing.Mapping and even _typeshed.SupportsItems do not cover these
types. For example,
samples/http-image-cloudevents/image_sample_server.py was failing to
type check where it calls `from_http(request.headers, ...)`.
To support these kind of headers types in from_http(), we now define our
own SupportsDuplicateItems protocol, which is broader than
_typeshed.SupportsItems.
I've only applied this to from_http(), as typing.Mapping is OK for most
other methods that accept dict-like objects, and using this more lenient
interface everywhere would impose restrictions on our implementation,
even though it might be more flexible for users.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* build: run mypy via tox
Tox now runs mypy on cloudevents itself, and the samples.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* build(ci): run mypy in CI alongside linting
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: fix minor mypy type complaint in samples
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* feat: use Mapping, not Dict for input arguments
Mapping imposes less restrictions on callers, because it's read-only and
allows non-dict types to be passed without copying them as dict(), or
passing dict-like values and ignoring the resulting type error.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: fix tests on py3.8
Tests were failing because the sanic dependency dropped support for
py3.8 in its current release. sanic is now pinned to the last compatible
version for py3.8 only.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* feat: support new model_validate_json() kwargs
Pydantic added by_alias and by_name keyword arguments to
BaseModel.model_validate_json in 2.11.1:
https://github.com/pydantic/pydantic/commit/acb0f10fda1c78441e052c57b4288bc91431f852
This caused mypy to report that that the Pydantic v2 CloudEvent did not
override model_validate_json() correctly. Our override now accepts these
newly-added arguments. They have no effect, as the implementation does
not use Pydantic to validate the JSON, but we also don't use field
aliases, so the only effect they could have in the superclass would be
to raise an error if they're both False.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: accept Mapping as well as SupportsDuplicateItems
Although our types.SupportsDuplicateItems type is wider than Dict and
Mapping, it's not a familar type to users, so explicitly accepting
Mapping in the from_http() functions should make it more clear to users
that a dict-like object is required for the headers argument.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
* chore: constrain deps to maintain py 3.8 support
Python 3.8 is unsupported and dependencies (such as pydantic) are now
shipping releases that fail to type check with mypy running in 3.8
compatibility mode. We run mypy in py 3.8 compatibility mode, so the
mypy tox environments must only use deps that support 3.8. And unit
tests run by py 3.8 must only use deps that support 3.8.
To constrain the deps for 3.8 support, we use two constraint files, one
for general environments that only constrains the dependencies that
python 3.8 interpreters use, and another for mypy that constraints the
dependencies that all interpreters use.
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>
---------
Signed-off-by: Hal Blackburn <hwtb2@cam.ac.uk>