tokenize.untokenize() misbehaves when moved to "compatiblity mode"

[ericsnowcurrently]

BPO	16224
Nosy	@terryjreedy, @ericsnowcurrently, @takluyver
Files	untokenize_compat_force_iter.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = <Date 2014-02-18.01:49:52.342>
created_at = <Date 2012-10-14.06:04:53.587>
labels = ['type-bug', 'library']
title = 'tokenize.untokenize() misbehaves when moved to "compatiblity mode"'
updated_at = <Date 2014-02-18.01:49:52.322>
user = 'https://github.com/ericsnowcurrently'

bugs.python.org fields:

activity = <Date 2014-02-18.01:49:52.322>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2014-02-18.01:49:52.342>
closer = 'terry.reedy'
components = ['Library (Lib)']
creation = <Date 2012-10-14.06:04:53.587>
creator = 'eric.snow'
dependencies = []
files = ['27560']
hgrepos = []
issue_num = 16224
keywords = ['patch']
message_count = 4.0
messages = ['172851', '172853', '180587', '211469']
nosy_count = 3.0
nosy_names = ['terry.reedy', 'eric.snow', 'takluyver']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue16224'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

[ericsnowcurrently]

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 bpo-16221).

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.

[ericsnowcurrently]

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 bpo-16221 into this patch. Consequently, if the patch is suitable, that issue can be closed.

[takluyver]

I think this is a duplicate of bpo-8478.

[terryjreedy]

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.