typeshed VS typeguard

"csv.pyi is from VS Code Pylance extension" is misleading. Yes, it's included in the code base of the extension, but it's likely originally from python/typeshed. I diffed csv.pyi in the extension and the repository, and they're exactly the same.

You can check the typeshed library that offers stubs for many packages.

https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.

https://github.com/python/mypy same with typeshed https://github.com/python/typeshed

Here's the tensorflow type stubs on typeshed. https://github.com/python/typeshed/tree/main/stubs/tensorflow

Also, be aware that there is already a central place for stubs files. If you are going to take the time to write one, contributing it there will help everyone if the package owners aren't already including some type hints.

Python's type hints are definitely an improvement and they're getting better all the time, but they're still frustrating to use at anything approaching the edge. I long for something as elegant and functional as TypeScript.

One hurdle I've stumbled over recently is the question "what is a type?", the answer can be surprising. Unions, for example, are types but not `Type`s. A function that takes an argument of type `Type` will not accept a Union. So if you want to write a function that effectively "casts" a parameter to a specified type, you can't. The best you can do is have an overload that accepts `Type` and does an actual cast, and then another that just turns it into `Any`. This is, in fact, how the standard library types its `cast` function [1]. The argument I've seen for the current behavior is that `Type` describes anything that can be passed to isinstance, but that's not a satisfying answer. Even then, `Union` can be passed to isinstance and still does not work with `Type`. Talk currently is to introduce a new kind of type called `TypeForm` or something to address this, which is certainly an improvement over nothing, but still feels like technical debt.

[1]: https://github.com/python/typeshed/blob/main/stdlib/typing.p...

>Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.

No, I really don't.

https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.

https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.

https://gitlab.alpinelinux.org/alpine/aports/-/merge_request... - I noticed that gnome-passwordsafe crashes some times, debugged it to discover that it was missing a dependency, sent a PR to the distro package to update the dependencies.

etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.

The csv module is one of those standard library modules that doesn't provide its own type hints, but instead gets them through the external typeshed project, and (for compatibility/implementation reasons, I surmise) the name of these types sometimes don't quite align with the objects they correspond to. So, for all intents and purposes, _csv._reader is the correct name of the type that csv.reader() returns, as ugly as it is.

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/

As other folks have commented, type hints are now a big deal. For static typing the best checker is pyright. For runtime checking there is typeguard and beartype. These can be integrated with array libraries through jaxtyping. (Which also works for PyTorch/numpy/etc., despite the name.)

I got good use of the run-time type checking of typeguard [0] when I recently invoked it via its pytest plugin [2]. For all code visited in the test suite, you get a failing test whenever an actual type differs from an annotated type.

[0]: https://github.com/agronholm/typeguard/

[1]: https://typeguard.readthedocs.io/en/latest/userguide.html#us...

But you can use a library like typeguard to get runtime typechecking. Or run mypy over the code to get static typechecking.

Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

> type hints are not binding.

There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

> Type checking is your job after all, ...[and that] requires maintenance.

There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

> There is an Any type and it renders everything useless

I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

> Duck type compatibility of int and float

The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

> Most projects need third-party type hints

Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

> Sadly, dataclasses ignore type hints as well

Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

> Type inference and lazy programmers

The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

> Exceptions are not covered [like Java]

I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

[0] https://github.com/RussBaz/enforce

[1] https://github.com/agronholm/typeguard

[2] https://github.com/microsoft/pyright

[3] https://pydantic-docs.helpmanual.io

[4] https://github.com/tiangolo/fastapi

[5] https://github.com/microsoft/pyright/blob/main/docs/configur...

[6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

Personally I find working around mypy's quirks to be more effort than it's worth, so to offer another option: typeguard or beartype can be used to perform run-time type checking.

Never checked? They're statically checked.

Also, tooling like https://pydantic-docs.helpmanual.io/ can do runtime checking for important parts of your app or you can add use this https://github.com/agronholm/typeguard to enforce all types at runtime (although I haven't measured the performance impact, probably something to do in a separate environment than production?).

typeguard