sourcery icon indicating copy to clipboard operation
sourcery copied to clipboard

The `use-dictionary-union` refactoring should not be suggested when projects support Python < 3.9

Open br3ndonland opened this issue 2 years ago • 3 comments

Issue description or question

The dictionary union operator was introduced in Python 3.9. Sourcery provides a use-dictionary-union refactoring to suggest the dictionary union operator.

The Sourcery GitHub app is recommending the use-dictionary-union refactoring on projects that support Python 3.8 and below.

Example: br3ndonland/fastenv#9

Furthermore, after rejecting the inappropriate use-dictionary-union suggestion, Sourcery opens another PR and makes the same suggestion again.

Example: br3ndonland/fastenv#10

And it just... keeps... going... br3ndonland/fastenv#11

Suggestions:

  • Read the supported Python versions from packaging configuration files like pyproject.toml or setup.py
  • Only suggest use-dictionary-union when the minimum supported Python version is 3.9.

Sourcery Version

Whatever is in the GitHub app

Code editor or IDE name and version

GitHub app

OS name and version

Linux: Ubuntu 20.04 (GitHub Actions)

br3ndonland avatar Apr 09 '22 20:04 br3ndonland

Hi - apologies for this. I think it would be better if we didn't reopen the sourcery PR once it has been manually closed.

You can configure a Python version in a .sourcery.yaml file in your project which should resolve this - see our docs here: https://docs.sourcery.ai/Configuration/Project-Settings/

Hellebore avatar Apr 10 '22 00:04 Hellebore

That sounds like a good plan - on your end, avoid opening multiple PRs, and on my end, set python_version to the minimum supported version with .sourcery.yaml.

Would love to see pyproject.toml support in the future as well (sourcery-ai/sourcery#159), and I do still think reading the Python version field from project metadata would be a sensible default (python_requires for setup.py, requires-python/python for pyproject.toml, etc).

br3ndonland avatar Apr 11 '22 21:04 br3ndonland

I do still think reading the Python version field from project metadata would be a sensible default

Agreed here, I just starred and got a huge PR full of f-string suggestions for a lib that supports py2

ddelange avatar May 18 '22 13:05 ddelange