Python-future: Replace lib2to3.fixes.fix_dict to avoid unnecessarily list() calls

Created on 8 Sep 2017 · 4Comments · Source: PythonCharmers/python-future

lib2to3.fixes.fix_dict will basically wrap any call to dict.keys(), .values() or .items() in list() no matter its context.

However as far as I can tell the calls are more or less pointless when the result is either directly iterated upon (e.g. for k, v in d.items()) or checked for containment (e.g. if a in d.keys()) leading to lots of diff-noise to revert.

Would be nice if python-future had its own dict-iteration fixer avoiding this annoyance.

0.21 enhancement

Source

xmo-odoo

👍9

Most helpful comment

Iterating views while adding or deleting entries in the dictionary may raise a RuntimeError or fail to iterate over all entries.

If the inside of the for loop is adding or deleting entries, then the list() is needed

r3m0t on 30 Nov 2018

👍2

All 4 comments

Iterating views while adding or deleting entries in the dictionary may raise a RuntimeError or fail to iterate over all entries.

If the inside of the for loop is adding or deleting entries, then the list() is needed

r3m0t on 30 Nov 2018

👍2

I've written my own "fix_dict_methods" that does this:

"""Fixer for some dict methods.

Imports these compatibility methods from `future.utils`.

d.iterkeys() -> iterkeys(d)
d.iteritems() -> iteritems(d)
d.itervalues() -> itervalues(d)

d.viewkeys() -> viewkeys(d)
d.viewitems() -> viewitems(d)
d.viewvalues() -> viewvalues(d)
"""

It should be safer for PY2 code that's slowly getting futurized step-by-step.

It doesn't wrap any of the simple .keys/values/items() calls in list() either, since I haven't found many spots we need that fix yet, but I might follow up with it as a separate step - I think I can run the normal fix_dict if I need that change.

Let me know if there is interest in this variant of fix_dict. I'm also up for changing its name. (Maybe fix_dict_methods_with_import?)

rdrey on 22 Apr 2020

👍1

Hi @rdrey, I am interested in this variant. Sound like a good idea to run it before the normal fix_dict, especially if the codebase always calls the iter version when it only needs iterator.

Do you mind sharing it?