Spurious PLE1300 error with 0.0.283

[DimitriPapadopoulos]

After upgrading v0.0.281 → v0.0.282 (codespell-project/codespell#3011) we see what we think is a spurious PLE1300 error:

• Minimal code snippet:

  s = "{0}{1:{width}}".format("a", "1", width=15)

• The command invoked:

  $ ruff --select PLE file.py 
  file.py:1:5: PLE1300 Unsupported format character '}'
  Found 1 error.
  $ 
  

• The current Ruff settings: no pyproject.toml file
• The current Ruff version:

  $ ruff --version
  ruff 0.0.283
  $ 
  

The Format String Syntax documentation states:

A format_spec field can also include nested replacement fields within it. These nested replacement fields may contain a field name, conversion flag and format specification, but deeper nesting is not allowed.

[MichaReiser]

This is probably related to #6171

[intgr]

I believe this occurred with the 0.0.282 -> 0.0.283 update, at least that's what caused it for me, not 0.0.281 → 0.0.282.

[DimitriPapadopoulos]

Perhaps I don't understand how pre-commit checks work. Our .pre-commit-config.yaml contains:

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.0.282
    hooks:
      - id: ruff

[DimitriPapadopoulos]

But yes, you're right about it, it's specific to 0.0.283:

$ pip install --force-reinstall --user ruff==0.0.281
Collecting ruff==0.0.281
  Downloading ruff-0.0.281-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (5.6 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.6/5.6 MB 11.0 MB/s eta 0:00:00
Installing collected packages: ruff
  Attempting uninstall: ruff
    Found existing installation: ruff 0.0.283
    Uninstalling ruff-0.0.283:
      Successfully uninstalled ruff-0.0.283
Successfully installed ruff-0.0.281

[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: python3 -m pip install --upgrade pip
$ 
$ ruff --select PLE file.py 
$ 
$ pip install --force-reinstall --user ruff==0.0.282
Collecting ruff==0.0.282
  Downloading ruff-0.0.282-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (5.6 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.6/5.6 MB 12.6 MB/s eta 0:00:00
Installing collected packages: ruff
  Attempting uninstall: ruff
    Found existing installation: ruff 0.0.281
    Uninstalling ruff-0.0.281:
      Successfully uninstalled ruff-0.0.281
Successfully installed ruff-0.0.282

[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: python3 -m pip install --upgrade pip
$ 
$ ruff --select PLE file.py 
$ 
$ pip install --force-reinstall --user ruff==0.0.283
Collecting ruff==0.0.283
  Using cached ruff-0.0.283-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (5.7 MB)
Installing collected packages: ruff
  Attempting uninstall: ruff
    Found existing installation: ruff 0.0.282
    Uninstalling ruff-0.0.282:
      Successfully uninstalled ruff-0.0.282
Successfully installed ruff-0.0.283

[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: python3 -m pip install --upgrade pip
$ 
$ ruff --select PLE file.py 
file.py:1:5: PLE1300 Unsupported format character '}'
Found 1 error.
$ 

I'm not a fan or pre-commit, it keeps annoying me, whether in CI jobs or on my own computer.

[kurtmckee]

pre-commit

ruff v0.0.283 is getting picked up by an unpinned ruff dev dependency running in a separate CI job. pre-commit is running v0.0.282 as specified.

[charliermarsh]

Thanks! I'll take a look at the format string parser. I wonder if we were silently parsing this incorrectly the whole time, and the rule just brought it to light, or if the changes to the parser from #6171 were erroneous.

[charliermarsh]

I think the parser doesn't quite support this, it'll need to be improved. (The rule was new in v0.0.283.)

[tdulcet]

This is still broken unfortunately. test.py:

import sys

number = 1234.56
print("{0:.{prec}g}".format(number, prec=sys.float_info.dig))

Ruff output:

$ ruff --select PLE1300 --isolated test.py
test.py:4:7: PLE1300 Unsupported format character 'g'
Found 1 error.

Ruff version:

$ ruff --version
ruff 0.0.285

There is a full example here that triggers two erroneous errors.

[DimitriPapadopoulos]

@tdulcet Perhaps you should open a new issue, since this one has been automatically closed.

[DimitriPapadopoulos]

I have opened #6767 as a follow-up to this ticket.