[_dain_]

>I'm concerned with what capabilities the input offers, not the name given to one particular implementation of that set of capabilities. If I have to think about it in any more detail than "`ducks` is an iterable of Ducklike" (n.b.: a code definition for an ABC need not actually exist; it would be dead code that just complicates method resolution) I'm trying to do too much in that function. If I have to care about whether the iterable is a list or a string (given that length-1 strings satisfy the ABC), I'm either trying to do the wrong thing or using the wrong language.

You can specify exactly that and no more, using the type system:

    def foo(ducks: Iterable[Ducklike]) -> None:
        ...

If you are typing it as list[Duck] you're doing it wrong.

[zahlman]

I understand that. The point is that I gain no information from it, and would need more complex typing to gain information.

I keep seeing people trying to wrap their heads around various tricky covariance-vs-contravariance things (I personally can never remember which is which), or trying to make the types check for things that just seem blatantly unreasonable to me. And it takes up a lot of discussion space in my circles, because two or more people will try to figure it out together.

[_dain_]

>The point is that I gain no information from it

No, you do gain information from it: that the function takes an Iterable[Ducklike].

Moreover, now you can tell this just from the signature, rather than needing to discover it yourself by reading the function body (and maybe the bodies of the functions it calls, and so on ...). Being able to reason about a function without reading its implementation is a straightforward win.

[zahlman]

>No, you do gain information from it: that the function takes an Iterable[Ducklike].

I already had that information. I understand my own coding style.

>Being able to reason about a function without reading its implementation is a straightforward win.

My function bodies are generally only a few lines, but my reasoning here is based on the choice of identifier name.

Yes, it takes discipline, but it's the same kind of discipline as adding type annotations. And I find it much less obnoxious to input and read.

[_dain_]

>I already had that information. I understand my own coding style.

Good for you, but you're not the only person working on the codebase, surely.

>My function bodies are generally only a few lines, but my reasoning here is based on the choice of identifier name.

Your short functions still call other functions which call other functions which call other functions. The type will not always be obvious from looking at the current function body; often all a function does with an argument is forward it along untouched to another function. You often still need to jump through many layers of the call graph to figure out how something actually gets used.

An identifier name can't be as expressive as a type without sacrificing concision, and can't be checked mechanically. Why not be precise, why not offload some mental work onto the computer?

>Yes, it takes discipline, but it's the same kind of discipline as adding type annotations.

No, see, this is an absolutely crucial point of disagreement:

Adding type annotations is not "discipline"!

Or at least, not the same kind of discipline as remembering the types myself and running the type checker in my head. The type checker is good because it relieves me of the necessity of discipline, at least wrt to types.

Discipline consumes scarce mental effort. It doesn't scale as project complexity grows, as organizations grow, and as time passes. I would rather spend my limited mental effort on higher level things; making sure types match is rote clerical work, entirely suitable to a machine.

The language of "discipline" paints any mistake as a personal/moral failure of an individual. It's the language of a blame-culture.

[zahlman]

> Good for you, but you're not the only person working on the codebase, surely.

I actually am. But I've also read plenty of non-annotated Python code from strangers without issue. Including the standard library, random GitHub projects I gave a PR to fix some unidiomatic expression (defense in depth by avoiding `eval` for example), etc. When the code of others is type-annotated, I often find it just as distracting as all the "# noqa: whatever" noise not designed to be read by humans.

And long functions are vastly more mentally taxing.

> often all a function does with an argument is forward it along untouched to another function. You often still need to jump through many layers of the call graph to figure out how something actually gets used.

Yes, and I find from many years of personal experience that this doesn't cause a problem. I don't need to "figure out how something actually gets used" in order to understand the code. That's the point of organizing it this way. This is also one of the core lessons of SICP as I understood it. The dynamic typing of LISP is not an accident.

> An identifier name can't be as expressive as a type without sacrificing concision

On the contrary: it is not restricted to referring to abstractions that were explicitly defined elsewhere.

> Why not be precise, why not offload some mental work onto the computer?

When I have tried to do it, I have found that the mental work increased.

> No, see, this is an absolutely crucial point of disagreement

It is.

[sevensor]

In my experience, arguing co versus contra is a sign you are working with dubious design decisions in the first place. Mostly this is where I punch a hole in the type system and use Any. That way I can find all the bad architectural decisions in the codebase using grep.