I think this is an instance of a very general problem and it kind of reminds me of the issues people have when trying to graft “nullability” information onto existing libraries that weren’t designed with nullability in mind..
Sounds reasonable in theory, a complete disaster in practice. (Best example: Kotlin’s Java support.)
The main lesson I learned is: If a language/library hasn’t been designed with X in mind, it’s not practical to add X as a third-party.
There are a lot of python APIs that “suffer” from casting.
In Django, you’ll see a lot of if isinstance(f, callable): f = f(), I’ve seen this in other places too. You get this with a lot of other libraries as well.
Of course, like many things that don’t fit static typing, this falls apart at the seams very easily. An example is that pandas series/dataframes do not like Django Querysets (because it’s not an instance of list, and so assumes it’s a dict or something weird). Despite the fact that querysets are perfectly iterable and usable like lists! An example of being too clever imo.
If you insist on using it though, the library author only has to write it once. Maybe it’s long, but that’s just the reality! Not writing it doesn’t mean there are no types. And it can still catch user-level bugs, so it’s helping the user (answering the author’s original request).
“Types are long” seems to be a bit different from “Types do not provide enough coverage”.
I guess the concern is there are some combinations of parameter types that are impossible to express with the new type hinting PEP (or in any type system for that matter). The nicest libraries in dynamic languages often make no sense, but they’re sure fun to use. A great example of gradual typing failure is in the type annotations for D3 in TypeScript (search for “any”).
I think this is an instance of a very general problem and it kind of reminds me of the issues people have when trying to graft “nullability” information onto existing libraries that weren’t designed with nullability in mind..
Sounds reasonable in theory, a complete disaster in practice. (Best example: Kotlin’s Java support.)
The main lesson I learned is: If a language/library hasn’t been designed with X in mind, it’s not practical to add X as a third-party.
There are a lot of python APIs that “suffer” from casting.
In Django, you’ll see a lot of
if isinstance(f, callable): f = f(), I’ve seen this in other places too. You get this with a lot of other libraries as well.Of course, like many things that don’t fit static typing, this falls apart at the seams very easily. An example is that
pandasseries/dataframes do not like DjangoQuerysets (because it’s not an instance oflist, and so assumes it’s a dict or something weird). Despite the fact that querysets are perfectly iterable and usable like lists! An example of being too clever imo.If you insist on using it though, the library author only has to write it once. Maybe it’s long, but that’s just the reality! Not writing it doesn’t mean there are no types. And it can still catch user-level bugs, so it’s helping the user (answering the author’s original request).
“Types are long” seems to be a bit different from “Types do not provide enough coverage”.
I guess the concern is there are some combinations of parameter types that are impossible to express with the new type hinting PEP (or in any type system for that matter). The nicest libraries in dynamic languages often make no sense, but they’re sure fun to use. A great example of gradual typing failure is in the type annotations for D3 in TypeScript (search for “any”).