fix: Better f-string spacing

[bricoletc]

Hmmm - I had a go at #220 and #227

I added tests for both in test_formatter.py, and the new code passes them.

A few thoughts & comments:

• It looks to me like black now (i.e., for python3.12) just ignores f-strings, i.e. doesn't reformat them, i.e. will let you do both, say:

  t=f"{1 + 2}"
  t2=f"{1+2}"

  On that basis the optimal solution for supporting the new tokenize in python 3.12 would be to basically ignore everything between tokenize.FSTRING_START and tokenize.FSTRING_END, extract the literal f-string that occurs there as a string, and just add that string in the buffer. That breaks our whole 'philosophy' though, of parsing tokens, one by one, and processing them
• So we have to add spaces inside f-strings as we're processing them, and we have to be consistent.
• What I decided is to introduce a reduced spacing syntax for f-strings: using fewer spacings than in our 'regular' spacing_triggers dictionary (in syntax.py). I now check for whether we are inside an f-string, both when performing python code parsing (in parser.py) and snakemake parameter parsing (in syntax.py), and if we are inside an f-string, we used the 'reduced spacing' syntax (dictionary fstring_spacing_triggers inside syntax.py)
• So, we now make a 'conscious choice' to format, say, f"{1 + 2}" as f"{1+2}" inside f-strings, from python>=3.12. Before 3.12, we accept both f"{1 + 2}" and f"{1+2}"; after, we reformat to the latter. I think that's fine, as black is fine with either. We're not because we parse f-strings, we don't ignore them. I think that's fine.
• All of this solves Addition of unwanted whitespaces when a function is called within an expression section of an f-string #220 because it removes the unnecessary spacing in our 'reduced spacing syntax'
• It also solves Removal of whitespace in f-string when used with python 3.12 (not with python 3.11) #227 because as I clearly establish when we're in or not in f-string context, we re-introduce proper spacing again

Let's see how robust this is as we move forwards...

[bricoletc]

P.S why does the PR state there are conflicts with origin/master?

And should I be PR-ing from bricoletc/master to trigger the checks that install/test/format the codebase?

[mbhall88]

Amazing work Brice! Thanks for this. I think this is the best solution given the situation. All feels like a house of cards though doesn't it haha.

Regarding the conflicts, you might not have had your fork/branch properly synced with the tip of master by the looks of it.

The easiest thing might be to make local copies of the files you've changed, delete this PR and branch, hard reset your master with snakefmt's master, then replace the files you changed with you local copy.