[Python-Dev] Type hints -- a mediocre programmer's reaction

[Cory Benfield]

On 21 April 2015 at 15:31, Chris Angelico <rosuav at gmail.com> wrote:
> Granted, there are some
> vague areas - how many functions take a "file-like object", and are
> they all the same? - but between MyPy types and the abstract base
> types that already exist, there are plenty of ways to formalize duck
> typing.

Are there? Can I have a link or an example, please? I feel like I
don't know how I'm supposed to do this, and I'd like to see how that
works. I'll even give a concrete use-case: I want to be able to take a
file-like object that has a .read() method and a .seek() method.

> And frankly, even with the uncertainties, I'd still rather
> have a function declared as taking a "file-like object" than "an
> object with a .read() method that takes an integer and returns up to
> that many bytes of data, and a .seek() method that blah blah blah
> blah". Sometimes, the precision is completely useless.

It is completely useless. Happily, this is a strawman, and no-one was
asking for it, so we can all live happily ever after!

The correct specification is "read method with this type signature"
and "seek method with this type signature". I would even be prepared
to waive the type signatures on read and seek, given that enforcing
the type hinting on others is not a good idea.

I suspect I have a mismatch with several others in this discussion. My
position is that if I'm going to have a type system, I'd like to have
a powerful one: Haskell, not Java. Otherwise I'll get by with the duck
typing that has worked just fine for us over the last 20 years. I
suspect, however, that many others in this conversation want any type
system at all, so long as they can have one.

Is that an accurate characterisation of your position, Chris?