Can we make the part of fix_dict that converts d.items/values/keys to
list(d.items) explicit? Most of the time, it's fine if the method
returns a view and can be a bit of a performance hit to convert it to a
list.

Rather, the list of special contexts in which it is ok to not use list()
should be extended.

Exactly! For example, if the .items call is in a for loop, list()
doesn't need to be called.

Here's a patch that doesn't add the enclosing list call in a for loop.

for k in d.keys():
   return k   # needs to return a list

>for k in d.keys():
>   return k   # needs to return a list

Could you explain this a bit more?

The example was mucked-up :(  The question is that when for-looping 
over d.keys/items etc, how you know that the body of the loop isn't 
going to mutate the dict?

I think the proper way to address this is via the confidence levels that
Rodrigo Bernardo Pimentel is adding for his Summer of Code project. The
idea is that you'll be able to say "let me inspect any changes where the
fixer is less than X% confident". fix_dict and for loops would be one
such place.

Until that mechanism is in place, I agree with Raymond that we should
err on the side of correctness.

Ok. I'll mark this as something to do for 2.7/3.1.

I haven't managed to successfully complete the summer of code, due to
some personal problems, but I'm still working on 2to3 and on confidence
ranking for it.

There's a bzr branch with its current implementation at
http://isnomore.net/bzr/2to3 . I did an initial implementation of
confidence penalties on fix_dict for special contexts.

I'm still working on it (and on confidence ranking in general), but
please take a look and let me know what you think.

(I've just realized it's not working properly for fix_dict; I'm fixing
it and will drop a note here when it is)

Is this still relevant?