4 ms·

A large majority of projects out there are not using type hints. You'd have to roll your own type hints. And sometimes, the type hints are impossible to upstrea

A large majority of projects out there are not using type hints. You'd have to roll your own type hints. And sometimes, the type hints are impossible to upstream: For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Dynamic languages have 'reflection' all over the place. Type systems are to terminate quickly, and if they don't, you are hacking them and they perform terrible (game of life in C++ templates and such). So even if performance is not the goal, you can't even get the correctness property right. In Haskell, there are libraries that will generate code from schemas, including migrations. They are typed to various degrees. There also shallow embeddings of the PostgreSQL query language (with types for the returned type, unlike the Mongoengine example before!). I just want to demonstrate that in Haskell, typing is not all-or-nothing either, but it is a spectrum, where a Haskell lib will typically end up being more typed than a Python lib. You could 'simplify' their type signatures (get dynamic typing) with GHC.Generic and you'd get something like what is common practice with Python. But it is pretty much impossible to go the other way.

kqr 6y ago
> For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Isnt this the case any time you use a DSL to query external data? Only sometimes someone else have type-hinted the things for you. I work in a strongly typed language (F#) that interops with JS, and one of our principles is to do the type checking on the F#--JS boundary and then not have to worry about it again.
dragonwriter 6y ago
> How will you typehint that? For that specific contrived scenario (mongoengine, which I've never used, apparently uses .aggregate for the latter rather than overriding .get) with two stub @overloads of [...].get for typehinting, one covering what it takes and gives in the aggregate case of interest and one for what it takes and gives in the simple case.

kqr 6y ago

> For example, let's say you use Mongoengine. Now, you can query a collection by using MyObject.objects.get(...) and it will return a MyObject. You might be able to make that work in Mypy. Now, you use some fancy aggregation feature, passing a dict into Mongoengine and it changes the type of the result you get back. How will you typehint that? I think the only way would be to special case it for all your queries. Isnt this the case any time you use a DSL to query external data? Only sometimes someone else have type-hinted the things for you. I work in a strongly typed language (F#) that interops with JS, and one of our principles is to do the type checking on the F#--JS boundary and then not have to worry about it again.

dragonwriter 6y ago

> How will you typehint that? For that specific contrived scenario (mongoengine, which I've never used, apparently uses .aggregate for the latter rather than overriding .get) with two stub @overloads of [...].get for typehinting, one covering what it takes and gives in the aggregate case of interest and one for what it takes and gives in the simple case.