```
>>> v = r"""f'\N  '"""
>>> import ast
>>> ast.literal_eval(v)
python: ../gpshead/Parser/string_parser.c:487: fstring_find_literal: Assertion `s == end || *s == '{' || *s == '}'' failed.
Aborted
```

this comes from oss-fuzz after enabling assert checks in its cpython builds. :)

https://oss-fuzz.com/testcase-detail/4805529363415040 & https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43730 for those who have access.

Adding Eric as this seems to be in the f-string parser.

I'll take a look.

This triggers the same problem:
f'\N  '
ast.literal_eval() isn't needed.

I think it's just the assert that's wrong, but I'm still checking.

Note that f'\N ' (with a single space) isn't enough to trigger this behavior. It requires at least two characters after the '\N'. The first is when the invalid string is recognized, and it's the presence of the second character that triggers the failed assert.

New changeset 0daf72194bd4e31de7f12020685bb39a14d6f45e by Eric V. Smith in branch 'main':
bpo-46503: Prevent an assert from firing when parsing some invalid \N sequences in f-strings. (GH-30865)
https://github.com/python/cpython/commit/0daf72194bd4e31de7f12020685bb39a14d6f45e

New changeset c314e3e829943b186e1c894071f00c613433cfe5 by Miss Islington (bot) in branch '3.9':
bpo-46503: Prevent an assert from firing when parsing some invalid \N sequences in f-strings. (GH-30865) (30867)
https://github.com/python/cpython/commit/c314e3e829943b186e1c894071f00c613433cfe5

New changeset 894e8c13484822458d53cc77c9265b7a88450a4b by Miss Islington (bot) in branch '3.10':
bpo-46503: Prevent an assert from firing when parsing some invalid \N sequences in f-strings. (GH-30865) (GH-30866)
https://github.com/python/cpython/commit/894e8c13484822458d53cc77c9265b7a88450a4b

Thanks for the quick fix, Eric!

In case anyone cares: in a non-debug build, this error had no real effect. It just caused the "find the literal part of an fstring" routine to terminate early, but since the part that it had already identified was still in error, a syntax error was still raised.

For "\Nxy" it would terminate at "\Nx", instead of consuming the whole string. But since "\Nx" isn't a valid string (bad unicode name escape), it would raise the same syntax error as "\Nxy".