Personally, I’m in the Richard camp, loving the extra checking the compiler gives me though I hate typing out instantiations like “Foo foo = new Foo()” that languages with little to no type inference (such as Java and C++) force you to do. C++ and Java both have terrible type systems, giving you all the pain of the extra typing with only really helping the developer at runtime at the subtle type displacements. What these languages missing are type inference.

Haskell, for example, has a fantastic type system. You specify what types a function takes and returns and if you violate this compact, either through function calls or returns, the compilation fails. This forces you to reason strongly about your program and the common thought in Haskell is if it compiles, it works. This even also allows Haskell to do crazy things like automatically generating testing suites–the type system is that strong. Even better, you don’t have t0 tell the compiler what type every value has, it figures it out for itself through its inference.

With disciplined developers and rigorous testing, (obviously) dynamic languages work. The issue with dynamic languages is that the developers have to be disciplined and the checks they have to put in to deal with the “what is this” issues is simply and elegantly handled with strongly, statically typed languages with good type inference.

Richard’s syntax is fine if all you’re interested in is the type. However, he is interested in the capabilities. So the part that didn’t make it into his post is that you’d have to define an interface-like structure somewhere to say what “iterable” means – what methods it has to support in order to satisfy the requirement. Then you get to the part where you also have to define the signatures for all those methods. If those methods have turkey type requirements, you have to define all of those subtypes somewhere too. To me, it seems easier to just do (pseudo)

if (foo.iter):
    for bar in foo:
        if isinstance(bar, SomeClass):
            bar.DoEeeeet()

I’ll concede that I’ve presented another weak example after pointing out weaknesses in Richards. Your point is well taken.

The more I think about it, the more I don’t see why this has to be a syntax change at all. I believe what Richard wants can be accomplished using some pretty generic helpers. Maybe I’ll talk to him about that possibility.

Where python really fails is that if you want this strictness, it makes it a horrible pain to achieve, if not impossible. And while I consider Richard’s syntax examples ugly, they’re far prettier than what someone has to do in python.

Your Photo/Video example is semi-silly. You know that even in these “generic” actions, the first time they were coded, they likely have Photo-specific code in them. So, you need to go through them and fix that when you decide you’re going to do video. That’s just a given. And if it truly generic, Richard’s Turkey-typing does not require superclasses, just you to specify [Photo,Video] instead of Photo, once you verify the method is not Photo-specific.

I tend to fall on Richard’s side on this one, but maybe that’s because I live in a world where sometimes the people you write code with weren’t hired for their coding, but instead for their knowledge of chemistry, and it just so happens that they need to write some code to try out some ideas, and you want it to be in an easy dynamic language, but you find them running into things like what Richard discusses in his posts. And C has different problems. I feel like Richard’s ideas would result in a better Python ecosystem, where there are clearer error messages instead of some deep backtrace of an uncaught exception (often from a C extension when you’re in the world of scientific computing, which means the deepest levels of the backtrace are not in Python and not your standard ValueError type problems).