[sethmlarson]

I use a separate method so that there's a definite type coming out of the function (typing.Iterator[str]) and would be impossible to determine the type of the iterator if we used the parameter route. Let me know what you think of that approach.

Closes #24

[lovelydinosaur]

Coolio!

Okay, so it looks to me like this can roughly be characterised as:

• Don't attempt to start decoding until we've got at least 512 bytes.
• If we've got between 512-4096 bytes, then see if we've figured out a decoding and start using it if we have.
• If we get to over 4096 bytes, the no more hanging around please - just start using whatever our best guess decoding is.

Have I got that right?

I think it'd be a good trade-off for us to switch to a simpler model here...

• Don't attempt to start decoding until we've got at least 4096 bytes. (Or we're done and flushed)
• Once we get there just start using whatever our best guess decoding is.

That'd give us more testable, and more determinate behavior, while still being an adequately small amount of initial buffering to be suitable for streamed data.

Seem reasonable?

[sethmlarson]

Yeah that works, I'll change it to that.

[sethmlarson]

This is ready for your review again @tomchristie

[lovelydinosaur]

As a rule I think we should probably prefer not to bother with "just in case", but deal with it if a bug report comes in. (At least then we have a verified case, and history to the code)