You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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=Noneclosed_at=<Date2021-10-20.22:45:21.073>created_at=<Date2014-02-23.11:11:47.707>labels= ['type-bug', 'expert-2to3']
title="2to3 zip fixer doesn't fix for loops."updated_at=<Date2021-10-20.22:45:21.073>user='https://github.com/drj11'
Activity
drj11 commentedon Feb 23, 2014
Consider the following code:
2to3 does not convert the zip in this code to list(zip(...)); it does not change this code at all.
That can be an (obscure) bug because the zip in Python 2 has different semantics from the zip in Python 3.
The output of this program
is different in Python 2 and Python 3 (when converted with 2to3, which doesn't change the program).
In Python 2 the output is:
ababA##
In Python 3 the output is:
ab#ab#A
Obviously this example is somewhat contrived, but I have a non-contrived example involving decoding PNG images (if anyone is interested).
peterotten commentedon Feb 23, 2014
Hm, I would expect that in 99 times out of 100 the extra list(...) would be removed in a manual step following the automated conversion.
I'd really like to see the non-contrived example with a justified use of this evil side effect ;)
RobertG commentedon Sep 28, 2014
As far as a non contrived example, see http://bugs.python.org/issue21628, which was marked as a duplicate of this bug.
This bug is the main thing preventing me from using 2to3, so I think it is a real issue.