[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)

Cory Benfield cory at lukasa.co.uk
Tue Apr 21 16:51:05 CEST 2015

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?

More information about the Python-Dev mailing list