Unless the tool does something more than its tagline, pyupgrade[1] offers the same functionality and much more.

[1]: https://github.com/asottile/pyupgrade

I don't mean to be rude, but what is the point ?

AFAIK the % operator is not deprecated. In fact % formatting being syntactically near identical to C is a feature to me. I use format strings as well depending on context.

% formatting being older doesn't mean it's obsolete.

That said it is cool to design a script to transform your code and any time you spent in the developing of automation is time earned.

> There is a case when this will behave different from the original - if var is a tuple of one element.

Hmm. I have a long habit of (almost) always using a one-element tuple. Consider:

    "foo %s" % x

  >>> x = "bar"
  >>> "foo %s" % x
  'foo bar'
  >>> x = ("bar",)
  >>> "foo %s" % x
  'foo bar'

  >>> "foo %s" % (x,)
  "foo ('bar',)"

  >>> from collections import namedtuple
  >>> x=namedtuple("Foo", "foo")("bar")
  >>> "foo %s" % x
  'foo bar'
  >>> "foo %s" % (x,)
  "foo Foo(foo='bar')"

    if isinstance(x, int):
      return f_int(x)
    elif isinstance(x, float):
      return f_float(x)
    else:
      raise ValueError("Unsupported value: %s" % (x,))

  % cat *.py */*.py | egrep -c '% \([a-zA-Z0-9_]+,\)'
  347

BTW, this is a great resource that compares the ways to do different formatting actions in two different styles - the %-based one (what they call "old style") and the .format one ("new style"): https://pyformat.info/

Having a choice on when to use the existing string formatting methods is a feature. I tend to use ‘%’ a lot for it’s compactness and f-strings most more rarely (admittedly there doesn’t seem to be much reason to use .format these days).

In general I don’t understand the need to hard-standardize code. Making subtle decisions depending on context is an important part of programming, please let humans decide and don’t use these types of tools in commit hooks...

Some years ago I made a script to backport a project I had developed in py3.6 on my free time but when I wanted to use it in prod at work it had to be py3.4: https://github.com/Galbar/norfs/blob/adb2a4ea885997352a1e24d...

It was a fun experience :)

It is only my personal opinion but I find the f-strings to be conceptually bad:

It might be a little bit easier to writer, but now you have magic and also code that is mixed within what should be simple strings. It is so easy to have suprising bad side effects because some operation would have been hidden in strings.

Slight tangent, but kudos for the quality of the readme. Thorough, complete and to the point.

Awesome! This was something I needed and wanted to write, thx for making it!

undefined

Do f-strings play nice with PyLint these days?

F strings are the f"ing shit"