Issue #3 resolved

Fixer for extended iterable unpacking?

Don Spaulding
created an issue

3to2 seemed to choke with ParseError's on input files that utilized PEP 3132-style extended iterable unpacking. Could this be fixed by assigning the right-hand side to a temporary identifier (not sure how you pick a name for it) and use it multiple times in a new assignment?

For example, could this: {{{ *head, a, b, c = range(10) }}}

Be fixed to something like: {{{ L = range(10) head, (a,b,c) = L[:-3], L[-3:] }}} The more I read PEP 3132, the more I realize how difficult this would be. Maybe the error message could be more suggestive when it runs across the following error.

RefactoringTool: Can't parse postgresql/versionstring.py: ParseError: bad input: type=16, value=u'*', context=('', (55, 2))

Comments (7)

  1. Joe Amenta repo owner
    • changed status to open

    3to2 does not yet take into account PEP 3132. The ParseError you encountered signals that 3to2's parser grammar needs to be modified to accept that syntax.

    I will go ahead and start writing a fix for this.

  2. Joe Amenta repo owner

    After a lot of aggravated manipulation of pgen2, pygram, and Grammar.txt, I have come to the conclusion that either I am just not smart enough, I haven't spent nearly enough time, or lib2to3 is not featureful enough to add the required star_expr and modify comparison to properly treat both of the following cases as grammatically correct:

    a, *b, c = range(5)
    

    and

    def a(*b, **c): pass
    

    I would appreciate it if someone better than me can figure this out and at least submit a patch that fixes the grammar to allow for PEP 3132-style assignments. Until then, I will put this bug on hold.

    With regards to making the error message more suggestive in this specific case, it would be a lot more work than it's worth. Though I cringe at the thought that anyone that takes advantage of extended iterable unpacking in py3k will have to see that error, it should be at least descriptive enough that a developer will be able to pinpoint what's causing it.

    I will, however, update my blog to point out this fact.

  3. Joe Amenta repo owner

    As of r157, the case of:

    a, b, c, *d, e, f = some_iterable
    

    is fixed. The only thing left to do is fix the (presumably less common)

    for a, b, *c, d in some_iterable_of_iterables:
        do_stuff
    

    case.

  4. Log in to comment