[PaulHoule]

As a Pythoner the most direct value I get out of types is the IDE being smart about autocompletion, so if I'm writing

   with db.session() as session:
      ... use the session ...

I can type session. and the IDE knows what kind of object it is and offers me valid choices. If there's a trouble with it, it's that many Pythonic idioms are too subtle, so I can't fully specify an API like

   collection = db["some_collection"]
   collection.filter(lambda doc: doc["amount"].as_integer() > 500)
   collection.filter({"name": "whatever"})
   collection.filter({"field": lambda f: f["subfield"] = jsonb({"a":1, "b":"2})})

not to mention I'd like to be able to vary what gets returned using the same API as SQLAlchemy so I could write

   collection.filter(..., yield_per=100)

and have the type system know it is returning an iterator that yields iterators that yields rows as opposed to an iterator that yields rows. It is simple, cheap and reusable code to forward a few fetch-control arguments to SQLAlchemy and add some unmarshalling of rows into documents but if I want types to work right I need an API that looks more like Java.

[maleldil]

If I understand correctly, you can do this with overloads. They don't change the function implementation, but you can type different combinations of parameters and return types.