When tokenize.untokenize() encounters a 2-tuple, it moves to compatibility mode, where only the token type and string are used from that point forward. There are two closely related problems: * when the iterable is a sequence, the portion of the sequence prior to the 2-tuple is traversed a second time under compatibility mode. * when the iterable is an iterator, the first 2-tuple encountered is essentially gobbled up (see ). Either an explicit "iterable = iter(iterable)" or "iterable = list(iterable)" should happen at the very beginning of Untokenizer.untokenize(). If the former, Untokenizer.compat() should be fixed to not treat that first token differently. If the latter, self.tokens should be cleared at the beginning of Untokenizer.compat(). I'll put up a patch with the second option when I get a chance.
Actually, here's a patch with the first option. It preserves iterators as iterators, rather than dumping them into a list. I've also rolled the tests from into this patch. Consequently, if the patch is suitable, that issue can be closed.
While I am closing this as a duplicate, I will use some of your patch, including one test, and credit you as well. Switching from 5-tuples to 2-tuples, as in one of your test cases, is not currently a supported use case, Compat currently re-iterates the entire token list and that does not work if some tokens have already been processed. While iter(iterable) makes your toy example pass, switching still does not work because of the problem of initializing compat. indents = [] This could only work with switching by making it a instance attribute which is also updated in the 5-tuple case. It is needed in tokenize also to support tab indents (#20383) but would only need to be an attribute instead of a local to support switching. startline = token[0] in (NEWLINE, NL) (my replacement for 3 lines) This is odd as the the file starts at the start of a line whether or not the first token is \n. On the other hand, the initial value of startline is irrelevant as long as it has some value because it is irrelevant until there has been an indent. It would also have to become an attribute to support switching and then it would be relevant since indents might not be initially empty. But I do not currently see the need for a tuple length switching feature. prevstring = False This does not matter even if wrong since it only means adding a space.
