On Tue, Apr 21, 2015 at 9:09 AM, Chris Angelico <ros...@gmail.com> wrote:
> ... > > 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 > Potentially you could use io.RawIOBase as the ABC for the type you need for FileLike, including read and seek. See the mixins in https://docs.python.org/3/library/io.html#class-hierarchy > > > That's not the type system's job. Not in Python. Maybe in Haskell, Not in Haskell either FWIW in terms of what its type system can prove > 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. RawIOBase is also potential overkill... maybe you just wanted something that duck typed for a few methods you implemented. Any and dynamic typing is a good choice then. > 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). > With what has been proposed, there are no static guarantees about how many bytes can be read, or that input is even seekable (does seekable() return True?) or it is open for reading. Instead we can only *prove* a limited amount in static type systems about the runtime dynamic behavior of code, and PEP 484 is weaker than other approaches (for very good reasons IMHO). Still useful however :) - Jim
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
