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

[Chris Angelico]

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:

* Provides a read() method which takes an integer and returns up to
that many bytes
* Provides a seek() method which takes two integers
* Is capable of relative seeking by at least 63 bytes backward
* Is open for reading
* Etcetera

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