Why does 2to3 change mydict.keys() to list(mydict.keys())?

Question

I'm looking at an output from 2to3 that includes this change:

-            for file_prefix in output.keys():
+            for file_prefix in list(output.keys()):

where output is a dictionary.

What is the significance of this change? Why does 2to3 do this?

How does this change make the code Python 3 compatible?

Secretary

try d.keys()[0] on python 2 and then on python 3 – Vicarious

Check this #16819722 – Washhouse

python.org/dev/peps/pep-3106 – Haugen

when the best change would be for file_prefix in output:, but py2to3 cannot guess that. – Wilder

Answer 1

In Python 3, the .keys() method returns a view object rather than a list, for efficiency's sake.

In the iteration case, this doesn't actually matter, but where it would matter is if you were doing something like foo.keys()[0] - you can't index a view. Thus, 2to3 always adds an explicit list conversion to make sure that any potential indexing doesn't break.

You can manually remove the list() call anywhere that a view would work fine; 2to3 just isn't smart enough to tell which case is which.

(Note that the 2.x version could call iterkeys() instead, since it's not indexing.)

Bellebelleek

see related issue here – Corvine

Answer 2

In Python 2.x, dict.keys() returns a list.

In Python 3.x, dict.keys() returns a view and must be passed to list() in order to make it a list.

Since the Python 2.x code doesn't need a list it should call dict.iterkeys() instead.

Trinatte

Answer 3

In Python 2, .keys() returns a list of the keys, but in Python 3 it returns a non-list iterator. Since 2to3 can't know whether you really needed the keys to be a list, it has to err on the side of caution and wrap the call in list so you really get a list.

Bullard

Answer 4

In Python2, keys returned a list while in 3 the return of keys is a dict_keys object. So if you were dependent on the list-result behavior, the explicit conversion is necessary.

Duplicate