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

Cory Benfield cory at lukasa.co.uk
Tue Apr 21 17:43:12 CEST 2015

On 21 April 2015 at 16:09, Chris Angelico <rosuav at gmail.com> wrote:

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

def incrementalparser(input: FileLike) -> List[Token]: tokens = [] data = "" while True: if not data: data = input.read(64) token = Token(data[0]); data = data[1:] while token.wantsmore(): token.givemore(data[0]); data = data[1:] tokens.append(token) if token.isendofstream(): 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 incrementalparser() 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).

Ok, that makes sense to me. =) Looking at mypy's source code, I see shutil.copyfileobj has the following signature:

def copyfileobj(fsrc: IO[AnyStr], fdst: IO[AnyStr], length: int = 16*1024) -> None:

so it seems that mypy defines a general IO datatype here.

I continue to be worried about the lack of a general solution to this problem, but I'm glad that some specific solutions exist. I still think library authors will not do much to take up this proposal. =)

More information about the Python-Dev mailing list