]> git.madduck.net Git - etc/vim.git/commit

madduck's git repository

Every one of the projects in this repository is available at the canonical URL git://git.madduck.net/madduck/pub/<projectpath> — see each project's metadata for the exact URL.

All patches and comments are welcome. Please squash your changes to logical commits before using git-format-patch and git-send-email to patches@git.madduck.net. If you'd read over the Git project's submission guidelines and adhered to them, I'd be especially grateful.

SSH access, as well as push access can be individually arranged.

If you use my repositories frequently, consider adding the following snippet to ~/.gitconfig and using the third clone URL listed for each project:

[url "git://git.madduck.net/madduck/"]
  insteadOf = madduck:

Improve f-string expression detection regex so ... (#2437)
authorRichard Si <63936253+ichard26@users.noreply.github.com>
Mon, 23 Aug 2021 02:52:19 +0000 (22:52 -0400)
committerGitHub <noreply@github.com>
Mon, 23 Aug 2021 02:52:19 +0000 (19:52 -0700)
commit8c04847aa22d14f01bb206cfc1b1e1cebd2ae538
tree12a072ae6fba401a1b1933d3e6324a45dc1dead7
parent104aec555fae0883ef5b53709569bd9c4d420bc5
Improve f-string expression detection regex so ... (#2437)

we don't accidentally add backslashes to them when normalizing quotes
because that's invalid syntax!

The problem this commit fixes is that matches would eat too much
blocking important matches to occur. For example, here's one f-string
body:

    {a}{b}{c}

I know there's no risk of introducing backslashes here, but the regex
already goes sideways with this. Throwing this example at regex101
I get:

    {a}{b}{c}   # The As and Bs are the two matches, and the upper
    ---- ----   # case letters are the groups with those matches.
    aAaa bbBb

... we've missed the middle expression (so if any backslashes in a
more complex example were introduced there we wouldn't bail out
even though we should -- hence the bug). As it stands the regex
needs somesort of extra character (or the start/end of the body)
around the expressions but that isn't always the case as shown
above.

The fix implemented here is to turn the "eat a surrounding non-curly
bracket character" groups ie. `(?:[^{]|^)` and `(?:[^}]|$)` into
negative lookaheads and lookbehinds. This still guarantees the
already specified rules but without problematically eating extra
characters ^^
CHANGES.md
src/black/strings.py
tests/data/string_quotes.py