In short:

    >>> f"\{10}"

yields:

    "\\{10"

This is reproducible only when `\` precedes the opening bracket, that is:

    >>> f"\ {10}"

results in: "\\ 10"

I'm not sure this counts as an error. The backslash means to treat the next character literally, which this does. And since \{ is not a valid escape sequence, it keeps both characters, exactly like:

>>> '\c'
'\\c'

Furthermore, since unknown escape sequences are deprecated, this usage is going to be an error in the future. You can see this now with -Werror:

$ python.exe  -Werror
Python 3.6.0b1+ (3.6:87de1f12c41c+, Sep 16 2016, 07:05:57) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f'\{10}'
DeprecationWarning: invalid escape sequence '\{'
>>> '\c'
DeprecationWarning: invalid escape sequence '\c'
>>>

Since this works as I expect it to now, and since it will become an error in the future, I don't think any change is warranted.

But I admit that dropping the trailing } seems odd. I think this particular usage should be an error: no bare } allowed, similar to:

>>> f'10}'
  File "<stdin>", line 1
SyntaxError: f-string: single '}' is not allowed

I see, the original "complaint" about this behavior on stack overflow was made due to the discrepancy between the f-string the the format "equivalent": '\{}'.format(10)'.

Do you have a link to the SO question?

Yes, should've attached in my previous message. See http://stackoverflow.com/questions/41330097/why-does-the-symbol-remain-when-f-10-is-evaluated-in-python-3-6

The problem is not that the trailing } is dropped, but that the starting { starts an f-string expression.

>>> f'\{2*5}'
'\\{10'

I expected either '\\10' as in '\{}'.format(2*5), or at least '\\{2*5}'.

There is other f-string parsing error:

>>> f'\\N{2*5}'
'\\N{2*5}'

I expected '\\N10'. '\\N' doesn't start a unicode name escape. This is a legitimate expression.

Yes:

>>> f'\{2*5}'
'\\{10'

I agree '\\10' would make sense.

This problem was no doubt introduced after 3.6a1 when I changed the parsing to disallow backslashes inside {}.

Proposed patch fixes parsing backslashes in f-strings.

P.S. Definitely we should find other name for this term. I hate misleading "f-string".

The PEP 498 should be updated to define the expected behaviour of f'\{5}':
https://www.python.org/dev/peps/pep-0498/#escape-sequences

+        self.assertEqual(f'\{6*7}', '\\42')
+        self.assertEqual(f'\\{6*7}', '\\42')
+        self.assertEqual(fr'\{6*7}', '\\42')
+
+        AMPERSAND = 123
+        self.assertEqual(f'\N{AMPERSAND}', '&')
+        self.assertEqual(f'\\N{AMPERSAND}', '\\N123')
+        self.assertEqual(fr'\N{AMPERSAND}', '\\N123')
+        self.assertEqual(f'\\\N{AMPERSAND}', '\\&')

I'm not sure that I like this behaviour.

f'\\N{AMPERSAND}': reading a local variable looks like a typo or a security vulnerability, rather than a nice feature.

IMHO if you want an anti-slash (\) in the output string, it *must* be written "\\" since we *do* interpret other escape sequences:

* f'\n' returns '\n', the newline character U+000A
* f'\N{Snowman}' returns the nice snowman character U+2603 (☃)
* etc.

What is the issue with having to write "\\{10}" to get "\\10" string? It's less error prone.

> f'\\N{AMPERSAND}': reading a local variable looks like a typo or a security vulnerability, rather than a nice feature.

This can look as a typo, but how would you write this if this is not a typo? f'\\N{AMPERSAND}' is legitimate syntax, and it would be weird to interpret this expression in any other way than as '\\' + 'N' + format(AMPERSAND).

> What is the issue with having to write "\\{10}" to get "\\10" string? It's less error prone.

There is no issue with f'\\{10}'. There is an issue with f'\{10}'.

> There is no issue with f'\\{10}'. There is an issue with f'\{10}'.

Hum, I'm not sure that my previous comment is explicit: I suggest to raise a syntax error on f'\{10}' (or emit a warning, and raise an error in 3.7 if you insist ;-)).

Updated patch adds a warning.

Ping.

Serhiy, since review activity has dropped on b.p.o now that the move to github was made, would you like to make this into a pull request to get it reviewed and merged faster?

I am not experienced with git and am waiting until new workflow be described in the devguide.

Serhiy: I plan to find time in the next week or so to look at this. Sorry for the delay. Plus, the new workflow isn't helping me out: I need to get up to speed on it.

Serhiy: if you want, you can give me your email and I'll submit a PR for you. If you want to do it yourself, just:

Download hub: https://hub.github.com/

git clone python/cpython cpython-git
cd cpython-git
git fork
curl https://raw.githubusercontent.com/mozilla/moz-git-tools/master/hg-patch-to-git-patch > hg-patch-to-git-patch
curl https://bugs.python.org/file46127/fstring_backslash_2.patch | python2 hg-patch-to-git-patch > fstring.patch
git checkout -b fstring-fix
git apply fstring.patch
git commit -am 'bpo-29104: Commit message here'
git push -u MY_GITHUB_USERNAME fstring-fix
git pull-request

A PR has been submitted, Ryan. See https://github.com/python/cpython/pull/490

Thank you Ryan. I already created a PR, but I think your recipe can be helpful for me in future.

Ping again.

Eric?

This is on my list of things to review at PyCon, when I should finally have some free time.

New changeset 0cd7a3f196cf34d9bb0a52e61327f7fe289d9750 by Serhiy Storchaka in branch 'master':
bpo-29104: Fixed parsing backslashes in f-strings. (#490)
https://github.com/python/cpython/commit/0cd7a3f196cf34d9bb0a52e61327f7fe289d9750

New changeset 89a310264000a613b7f6abd5916946aef09ae7d2 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-29104: Fixed parsing backslashes in f-strings. (GH-490) (#1812)
https://github.com/python/cpython/commit/89a310264000a613b7f6abd5916946aef09ae7d2