My question is this: What happened to all the duck-typing evangelism? "If it walks like a duck and quacks like a duck, it is a duck", "static typing only catches trivial errors", and so on.

> "static typing only catches trivial errors",

That's partly because we tend to use the same types for everything. For instance in a spreadsheet you can subtract a column number from a row number and get no complaints even though the difference between the two quite likely makes no sense. If you have a separate type for row numbers and column numbers such mistakes can be caught.

In your example you'd just have two different types with no subtraction operation defined between them. That has nothing to do with type hints.

What you probably meant: This is where being strongly typed helps. Python is and always has been strongly typed.

Everything is cyclical. Pain is forgotten, same mistakes are made, pain is rediscovered, relief is reinvented. I had a high school teacher who said something like, "I haven't bought new ties for 25 years. Why? Because things always go in and out of fashion. A particular tie might be out of fashion for ten years but it comes back eventually."

I use typing at interface boundaries within code and sometimes between functions. Within a function I use duck typing. As others have mentioned, I use this more as an editor hint to warn me of questionable behavior and almost never run mypy. Yes, it only catches trivial errors, but a trivial error highlighted in the editor is easy to see/fix. The extra typing in the function sig is saved in not having to enter the same info in the docstring, so it feels like a wash to me.

Back when static typing meant Java or worse, it was reasonable to think horribly verbose and clunky programming was inherent to static typing. But now we know better.

Not a definitive answer to the problem but mypy supports a limited sets of common "interfaces", for instance dict-like or list-like.

http://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html#st...

That's right, mirroring the built in (3.x) abc collections heirarchy. Which then allows you to do interesting things like delegation based polymorphism by registering with the appropriate metaclass so - just to come back to your parent's point - interrogating the type reveals it to be list-like or dict-like.

Ah, that makes things better

It's still here. Types don't matter in many scenarios. Example: get a parameter from a POST, use it as a key to query the db, store it into the db. Is it a string, is it an int? It doesn't really matter to the application because the db driver can handle that. Don't slow me down by making me look at the docs of what I really receive from the web server to declare a type. Multiply by some hundred or thousand times. Strongly typed languages only raise costs for my customers. Given that the budget is constant they get more features with dynamically typed languages.

I'm not happy seeing language designers introducing strong or optional typing in languages that didn't have it, but I understand that their goals are different from the goals of the developers that use their languages. I'd say leave the core of Python (and Ruby [1]) alone: if we picked those dynamically typed languages in the last 25 years (they're that old) it means we like them so. We can use plenty of other languages if we really need types.

[1] https://blog.heroku.com/ruby-3-by-3 "Matz: ... the third major goal of the Ruby 3 is adding some kind of static typing whille keeping the duck typing, so some kind of structure for soft-typing or something like that. The main goal of the type system is to detect errors early. So adding this kind of static type check or type interfaces does not affect runtime."

> Example: get a parameter from a POST, use it as a key to query the db, store it into the db.

So you get a string, and you want to pass it unmodified to something that expects a string? The static typing answer is simple: Your variable is a string! How does that slow you down, or cost your customers a single cent?

I really don't know if it's a string. AFAIK the framework could give my ints when it sees a number. I should check, but what for? I'll do the next time I need to do some math on those values and then forget again. They're not the things developers should waste time with.

> I really don't know if it's a string. AFAIK the framework could give my ints when it sees a number.

In addition to alexvoda's comment: If you don't know what you get from your framework, then how do you know that you database frontend can handle it? Maybe in some cases, your framework gives you a list of lists, or a hashmap, and your database has no idea what to do with it. I really hope that's not the level of thoroughness you spend on your professional work.

Besides, if your framework were statically typed, it would either give you a String, or some kind of Variant/Any/Object with a to_string() method, the output of which can be passed to your database. There, problem solved, no time wasted, and you can be sure that whatever your framework does, your database can handle it.

Typical response from someone looking at things not from the database side. Someone who mainly works with the database will cringe at the thought of just throwing whatever data into the database. Consistency, integrity and all that jazz.

Different areas of programming give importance to different things.

Being able to lock down known interfaces can be beneficial, while leaving the rest open. Optional typing also lets you ignore the type hints when you really know what you want to do.

> "static typing only catches trivial errors"

To be honest I've not seen that sentiment very often, and it's definitely not something I agree with.

There exist libraries that provide 'duck types' and other goodness for type hinting.

typecheck [0] is one (which can also run-time enforce the check) used like:

    import typecheck as tc


    def logathing(
        dest: tc.hasattrs('write'),
        thing: tc.any(int, float, str),
        prefix: tc.optional(str)=None
    ):
        dest.write(prefix + str(thing) if prefix else str(thing))

[0] - https://github.com/prechelt/typecheck-decorator