Technically Python is now an optionally-typed language, as of version 3.5. It won't actually check the types out-of-the-box, but it has support for annotating variables and functions with their types. A separate project (mypy) can then read and check those types, and it does some inference too.

You can see typed examples here: http://mypy-lang.org/examples.html

>Type inference has spread everywhere that the old argument of having to repeat your types doesn't hold anymore.

Indeed. I find one of the most elegant recent examples is this snippet in Kotlin (yes, this is fully and statically typed): https://kotlinlang.org/docs/reference/type-safe-builders.htm...

  import com.example.html.*
  
  fun result(args: Array<String>) =
    html {
        head {
            title {+"XML encoding with Kotlin"}
        }
        body {
            h1 {+"XML encoding with Kotlin"}
            p  {+"this format can be used as an alternative markup to XML"}

            // an element with attributes and text content
            a(href = "http://kotlinlang.org") {+"Kotlin"}

            // mixed content
            p {
                +"This is some"
                b {+"mixed"}
                +"text. For more see the"
                a(href = "http://kotlinlang.org") {+"Kotlin"}
                +"project"
            }
            p {+"some text"}

            // content generated by
            p {
                for (arg in args)
                    +arg
            }
        }
    }

Count me in. And not only when working in teams. Sometimes that other person is you, after half year or more, and you need to figure out what the hell i was thinking when i was writing this code.

"I used to think several years ago, that the main benefit of strong static typing was code safety / eliminating a whole class of bugs. But I've changed my opinion. I now think the biggest benefit is that it makes the code a lot easier for other people to read and understand."

Obfuscated spaghetti code and write-only programs can be written in any language. I've seen plenty of convoluted OCaml programs, with tons of one-letter variable names and no comments. And don't get me started on Haskell's propensity for using dozens of non-alphabetic operators that make it read more like line noise than Perl, not to mention its famous easy to understand monads or easy to reason about lazyness, on top of the community propensity for one-letter variable names, same as with OCaml. Static typing does not save badly written programs in either of these languages.

Besides, you can add type annotations to your Python programs, and even have them checked by mypy. Those programs might even wind up being easier to read than programs written in a statically-typed language where the programmer relied on type inference. But they won't necessarily be any more readable, as readability has less to do with types than it does with the programmer and the reader.

this is exactly my biggest pain-point of dynamic typing (which I do at work): you can't know how a datastructure looks like. Just knowing the fields that are present is something I would like to have.

I thought the most recent Clojure Conj keynote by Rich Hickey (caveat: that guy could sell me the Brooklyn Bridge) did a good job selling dynamically typed languages.

As he makes a pretty good case for, there’s a lot to like about dynamically typed languages. But, everywhere I look in Clojure, I feel like the language is more principled than Python. There’s also Spec, which allows developers to exercise even more rigor without jumping to static types.

Going even further, Racket lets you move to a type system as you want to, but not before.

I’d like to imagine that there’ll be more of these middle ground approaches over time, without having to commit to either the freewheeling status quo of Python or the rigidity of Haskell.

EDIT: I should note that even Python is moving that way as there are now optional type annotations.

> It's really sad when I see `foo(bar)`, and I have no idea what the type of `bar` is, and if it's an object, I have no idea what fields `bar` has

With a statically typed language, you still have to look through the code to find the definition of an object. I believe that can be avoided by having easy to access to documentation which would also apply to dynamically typed languages like Python.

Or just treat id as whatever and pass it on the service. If it quacks like a duck, it's a duck.

Do you mind elaborating? Neither C nor Python have type inference as part of the language, so it's hard to tell exactly what you mean.

There is so much wrong with this...

> Safety: Each data carries it's type at run-time

With a statically typed language, this is not necessary for safety, since the compiler has already checked that the types are correct.

> there are no overflow

Do you mean integer overflow? This is completely orthogonal to the static/dynamic typing distinction.

> or NULL ptr problems as in statically typed languages

This is also completely orthogonal to the static/dynamic typing distinction. Remember that C and C++ do not constitute the entirety of statically typed languages.

> E.g. arithmetic is exact

What does this even mean?

> Memory Safety.

Again, C and C++ do not constitute the entirety of statically typed languages.

I'm sorry, but I have to disagree with the first point. Static vs dynamic typing doesn't have much to do with safety. Haskell, Standard ML, OCaml, Rust, and many others have memory safety and no null pointer issues. Exact arithmetic and overflow also has nothing to do with type systems. There are statically typed languages other than C and C++, and virtually all of them from the last 20 or more years address the issues you list here.

(I personally would also disagree with your second point, but that is more a matter of opinion.)

That's an odd consensus since neither exact arbitrary-precision arithmetic nor run-time type information, nor null or memory safety have anything to do with the static/dynamic distinction.

I think there's also no consensus that forcing you to run code to (maybe, if you happen to have chosen the right input values) find errors that could be caught statically really makes it easier to develop.