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

Chris Angelico rosuav at gmail.com
Tue Apr 21 17:09:52 CEST 2015

On Wed, Apr 22, 2015 at 12:51 AM, Cory Benfield <cory at lukasa.co.uk> wrote:

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.

Someone who's been more involved in the details of MyPy can probably say more specifically what ought to be done about file-like objects.

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?

Pretty accurate, yeah. Here's how I see it:

def incremental_parser(input: FileLike) -> List[Token]: tokens = [] data = "" while True: if not data: data = input.read(64) token = Token(data[0]); data = data[1:] while token.wants_more(): token.give_more(data[0]); data = data[1:] tokens.append(token) if token.is_end_of_stream(): break input.seek(-len(data), 1) return tokens

If you were to exhaustively stipulate the requirements on the file-like object, you'd have to say:

That's not the type system's job. Not in Python. Maybe in Haskell, but not in Python. So how much should go into the type hint? I'm happy with "FileLike" or however it's to be spelled; maybe separate readable files from writable ones, as those are two fairly clear variants, but that's about all you really need. If you provide incremental_parser() with an input file that's non-seekable, it's going to have problems - and your editor may or may not even be able to detect that (some files are seekable but only in the forward direction, but they'll have the exact same seek() method).

I might be wrong about where MyPy is trying to go with this, but doubtless someone will correct me on any inaccuracies above.

ChrisA

More information about the Python-Dev mailing list