Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
flakeheaven
flakeheaven is a python linter built around flake8 to enable inheritable and complex toml configuration.
Woah, Pyright is written in Node? And it has its own [parser](https://github.com/microsoft/pyright/blob/b74be3b2cb2c5d35b9...)? That's really interesting. I wonder how it compares to Mypy on speed.
> The main thing that eventually forced decision was a flaky (depends on cache) mypy crash using paramspecs half a year ago. At time paramspec support was still in progress and there’s a good chance that specific issue is fixed.
I actually think I ran into this exact issue (ParamSpec-related, only fails when reading from cache, etc.), which led me to pin a Mypy development version for a while and was fixed recently.
You have to do handling like that in other languages like TypeScript anyway.
Painpoint with type annotations:
- not being able to reuse "shapes" of data: TypedDict, NamedTuple, dataclasses.dataclass, and soon kwargs (PEP 692 [1]) all have named, typed fields now. You have to
- Since there's no generic "shape" structure that works across data types, there isn't a way to load up a JSON / YAML / TOML into a dictionary, upcast it via a `TypedGuard`, and pass it into a TypedDict / NamedTuple / Dataclass. dataclasses.asdict() or dataclasses.astuple() return naive / untyped tuples and dicts. Also the factory functions will not work with TypedDict or NamedTuple, respectively, even if you duplicate the fields by hand. See my post here: https://github.com/python/typeshed/issues/8580
- Standard library doesn't have runtime validation (e.g. pydantic / https://github.com/pydantic/pydantic).
- pytest fixtures are hard.
- Django is hard. PEP 681 may not be a saving grace either. [3]
[1] https://peps.python.org/pep-0692/
I am moving all my open source projects to `mypy --strict`. Here's the diff of adding basic / --strict mypy types:
libvcs: https://github.com/vcs-python/libvcs/pull/362/files, https://github.com/vcs-python/libvcs/pull/390/files
libtmux: https://github.com/tmux-python/libtmux/pull/382/files, https://github.com/tmux-python/libtmux/pull/383/files
unihan-etl: https://github.com/cihai/unihan-etl/pull/255/files, https://github.com/cihai/unihan-etl/pull/257/files
As for return on investment - not sure yet. What I like about it is:
- completions (through annotating)
- typings can be used downstream (since the above are all now typed python libraries)
- maintainability and bug finding. Easy to wire into CI and run locally.
There's a thread on mypy, "--strict is too strict to be useful", https://github.com/python/mypy/issues/7767. I'm not sure if I walked away with that impression. If I have a function that could potentially return `None` (`Optional[str]` or `str | None`) - it makes sense for the user to handle such a case. They could:
assert response is not None
I am moving all my open source projects to `mypy --strict`. Here's the diff of adding basic / --strict mypy types:
libvcs: https://github.com/vcs-python/libvcs/pull/362/files, https://github.com/vcs-python/libvcs/pull/390/files
libtmux: https://github.com/tmux-python/libtmux/pull/382/files, https://github.com/tmux-python/libtmux/pull/383/files
unihan-etl: https://github.com/cihai/unihan-etl/pull/255/files, https://github.com/cihai/unihan-etl/pull/257/files
As for return on investment - not sure yet. What I like about it is:
- completions (through annotating)
- typings can be used downstream (since the above are all now typed python libraries)
- maintainability and bug finding. Easy to wire into CI and run locally.
There's a thread on mypy, "--strict is too strict to be useful", https://github.com/python/mypy/issues/7767. I'm not sure if I walked away with that impression. If I have a function that could potentially return `None` (`Optional[str]` or `str | None`) - it makes sense for the user to handle such a case. They could:
assert response is not None
I am moving all my open source projects to `mypy --strict`. Here's the diff of adding basic / --strict mypy types:
libvcs: https://github.com/vcs-python/libvcs/pull/362/files, https://github.com/vcs-python/libvcs/pull/390/files
libtmux: https://github.com/tmux-python/libtmux/pull/382/files, https://github.com/tmux-python/libtmux/pull/383/files
unihan-etl: https://github.com/cihai/unihan-etl/pull/255/files, https://github.com/cihai/unihan-etl/pull/257/files
As for return on investment - not sure yet. What I like about it is:
- completions (through annotating)
- typings can be used downstream (since the above are all now typed python libraries)
- maintainability and bug finding. Easy to wire into CI and run locally.
There's a thread on mypy, "--strict is too strict to be useful", https://github.com/python/mypy/issues/7767. I'm not sure if I walked away with that impression. If I have a function that could potentially return `None` (`Optional[str]` or `str | None`) - it makes sense for the user to handle such a case. They could:
assert response is not None
I am moving all my open source projects to `mypy --strict`. Here's the diff of adding basic / --strict mypy types:
libvcs: https://github.com/vcs-python/libvcs/pull/362/files, https://github.com/vcs-python/libvcs/pull/390/files
libtmux: https://github.com/tmux-python/libtmux/pull/382/files, https://github.com/tmux-python/libtmux/pull/383/files
unihan-etl: https://github.com/cihai/unihan-etl/pull/255/files, https://github.com/cihai/unihan-etl/pull/257/files
As for return on investment - not sure yet. What I like about it is:
- completions (through annotating)
- typings can be used downstream (since the above are all now typed python libraries)
- maintainability and bug finding. Easy to wire into CI and run locally.
There's a thread on mypy, "--strict is too strict to be useful", https://github.com/python/mypy/issues/7767. I'm not sure if I walked away with that impression. If I have a function that could potentially return `None` (`Optional[str]` or `str | None`) - it makes sense for the user to handle such a case. They could:
assert response is not None
You have to do handling like that in other languages like TypeScript anyway.
Painpoint with type annotations:
- not being able to reuse "shapes" of data: TypedDict, NamedTuple, dataclasses.dataclass, and soon kwargs (PEP 692 [1]) all have named, typed fields now. You have to
- Since there's no generic "shape" structure that works across data types, there isn't a way to load up a JSON / YAML / TOML into a dictionary, upcast it via a `TypedGuard`, and pass it into a TypedDict / NamedTuple / Dataclass. dataclasses.asdict() or dataclasses.astuple() return naive / untyped tuples and dicts. Also the factory functions will not work with TypedDict or NamedTuple, respectively, even if you duplicate the fields by hand. See my post here: https://github.com/python/typeshed/issues/8580
- Standard library doesn't have runtime validation (e.g. pydantic / https://github.com/pydantic/pydantic).
- pytest fixtures are hard.
- Django is hard. PEP 681 may not be a saving grace either. [3]
[1] https://peps.python.org/pep-0692/
> I'd run flake8 too but the maintainer is weirdly opposed to supporting pyproject.toml for config.
I haven't used it in anger yet, but FlakeHeaven (https://github.com/flakeheaven/flakeheaven) looks like a nice fork that includes pyproject.toml support.