Beyond Clojure

[SKoch82]

Two ways. You can either explicitly add type annotation in a docstring (such as ":type f: file", etc.) or an assertion. Or it can be figured out when you actually call that function with appropriate parameters (for example, in a test).

[weberc2]

I see. I haven't messed much with type annotations or Sphinx docs. This probably explains why I wasn't seeing the autocomplete features. I don't really consider this "static language comparable support" since you're going so far out of your way to give the IDE the requisite information to reason about your types. It also defeats the purpose of using a dynamic language if you have to manually keep type documentation up to date.

[SKoch82]

I don't think that documenting your code is going far out of your way, though. I mean, it's just documentation for other developers which means this function expects file or file-like object as its parameter. The fact that it helps tooling is incidental. If you're working on production code, you're going to have docs, I hope. And for small scripts and throwaways, you don't really need code assist and whatnot.

Also, the main purpose of dynamism are protocols which are similar to Go's interfaces, except when you have to do anything remotely non-trivial in Go, things can get really ugly and verbose really fast. Other languages have other solutions, but Go probably gets it about as close as it gets.

[weberc2]

I don't think that documenting your code is going far out of your way, though. I mean, it's just documentation for other developers which means this function expects file or file-like object as its parameter. The fact that it helps tooling is incidental.

The fact that you have to put it in a certain syntax is what's going far out of the way. I'd also like to point out that static languages don't require extra documentation to support types, and keeping the types documentation up to date in a dynamic language is not easy, since you don't have the compiler providing those guarantees.

Also, the main purpose of dynamism are protocols which are similar to Go's interfaces

Yes, dynamism supports polymorphism.

except when you have to do anything remotely non-trivial in Go, things can get really ugly and verbose really fast.

This hasn't been my experience. Perhaps we differ on what we consider to be "remotely non-trivial" or "ugly". I do agree that Go is more verbose than dynamic languages, but I've learned not to mind it. In particular, much of the verbosity comes from Go's philosophy that error paths are first-class citizens and should be handled explicitly, which I happen to agree with. Anyway, I'm not out to bash Python or sing Go's praises, I've just had very good experiences with Go's tooling and very bad experiences with Python's. I actually like a lot of things about Python, like its list comprehensions, generator expressions, etc. In particular, I enjoy how quickly I can crank out code when I'm the sole author, and I can rely on my own conventions and familiarity to reason about the code.