[M001N]

Summary

Added raw field to FStringNode, set from the FSTRING_START token's prefix ('r' in token.rstrip('"\'').lower()) when it is pushed onto fstring_stack. Added two new regexes, fstring_raw_string_single_line and fstring_raw_string_multi_line, used by find_fstring_string() instead of the normal fstring_string* regexes when tos.raw is True. These treat backslash as ordinary literal text (no \N{...} handling, no backslash+char escape pairing) while still: matching {{/}} doubled-brace literals correctly, stopping the match at a bare {/} so expressions still open normally, and preserving backslash-newline line continuation for single-line raw f-strings (verified against CPython's actual raw-string continuation behavior). Non-raw f-string regexes/behavior are untouched.

Problem

davidhalter/parso issue reference: #197

Root Cause

Confirmed the discovery hypothesis. In parso/python/tokenize.py, fstring_string_single_line/fstring_string_multi_line (used by _find_fstring_string()) unconditionally matched a backslash followed by any non-newline/non-N character (\\[^\r\nN] / \\[^N]) as a single escaped literal unit, so \{ was swallowed as plain text instead of opening a replacement field. FStringNode (constructed at the FSTRING_START token) never tracked whether the f-string's prefix contained 'r'/'R', so this non-raw escaping behavior was wrongly applied to raw f-strings too, where backslashes have no escaping effect.

Testing

PASS - all 78 test_fstring.py cases pass (including 8 new raw-f-string cases covering the reporter's exact case, fr/rf/Rf/fR prefix orderings, escaped backslash, doubled braces, triple-quoted raw f-strings with line continuation, and an invalid raw single-'}' case), and the full suite passes at 1994 passed, 0 failed.

Related Issue

#197

[davidhalter]

Hi, I'm sorry to say this, but I decided to not work at all with AI generated pull requests/content. There are multiple reasons for this:

1. I feel like at this point it's pretty subpar to what a good engineer can create. I have received many AI generated pull requests and they all have massive problems compared to what I received from actual people. People sometimes can't fix the problems they have without AI, but I regard this as a feature: If you don't understand the problem, I don't have to review your code.
2. I love people. And I would like to interact with all of you; learn from you; teach you. But if you are simply a bridge to an LLM, I'm just wasting my time. I cannot build any form of relationship.
3. LLMs are the antithesis to what I like about programming. I like the struggle of programming. Of writing code. I love how things come together after a good coding session. This is all missing. And while some form of AI might make that skill useless in the future, it's not useless now and I would really recommend anyone to avoid LLMs for generating complex code.
4. Even for written English I generally prefer non-LLM text, because it shows something about the person. I understand that some people are incredibly non-fluent, but that's fine. Just do your best and try to learn English. Otherwise we won't have the ability to talk if we ever meet, which would be a pitty.
5. LLMs are extremely good at generating code/text that looks reasonable. I use them a lot for brainstorming, they are incredible at putting out ideas. They are bad at facts. They are really bad at thinking. The positive thing here is that you have a brain and you can use it to think. Think hard first.
6. LLMs tend to generate lots of code that is then hard to review. Try to contribute small changes first.

Thank you anyway for trying to contribute to Open Source. I would really appreciate if you avoid the usage of LLMs in my projects. It is obviously fine to use LLMs as a search/brainstorming tool with my projects, just don't use it to interact with me.

PS: As a side note I want to mention that I'm probably not the only maintainer that has a difficult relationship with LLM content. So you probably should ask first before you use LLMs for other repositories.