The Glossary section should mention f-strings, starting in Python 3.6.

"f-string" is widely used, but misleading term. It is not used in the documentation. But "formatted string literal" is not better. This isn't literal, this isn't special kind of strings, this is a special formatting expression resulting to string.

There was a discussion on Python-Dev about better term, but it didn't come to any conclusion.

When I wrote the documentation <https://docs.python.org/dev/reference/lexical_analysis.html#f-strings>, I think I tried to avoid “f-string”, being jargon, and used more formal terminology from PEP 498 instead. But I agree they more than regular literals.

Serhiy do you have a link/message-id/etc of the Python-dev discussion? All I found with Google was <https://www.reddit.com/r/Python/comments/3k969r/lets_find_a_better_name_for_fstrings/>. One other goal is to differentiate these from other formatted strings, such as from str.format and percent formatting.

* formatted strings (doesn’t differentiate from str.format, etc)
* string interpolations
* string expressions
* string comprehensions (apparently too far removed from set comprehensions)
* Maybe format(ted) string displays? (parallelling list etc displays)

I don't have a link. There were a lot of threads about this feature and I didn't follow them. After implementing PEP 498 there was a discussion about terminology.

I read discussions about coming and released Python 3.6 on StackOverflow, Reddit and other resources and seen a lot of misinterpretation due to using terms "string" and "literal".

It's odd how 'f-string' just caught on when byte, raw and unicode strings never really did (at least I personally don't see many people using b-string, r-string and u-string respectively).

Shouldn't an entry for them be made too if 'f-string' would be added?

As for the name used by everyone, you can't blame them, f-string is a term used throughout PEP 498.

I guess a a new discussion might be warranted where people can decide if a new term should be thought of or if the negative effects of using the current aren't all that bad.

"raw" and "byte" are one syllable names, and thus as easy and more meaningful to say than "r-string" or "b-string".  "unicode string" is more descriptive and not much longer, but "u-string" does occasionally get used, though mostly in a python3 context where you want to differentiate it from normal unadorned unicode strings.  If you want to replace 'f-string' in the vernacular, you need a one or two syllable word that is descriptive.  The only real candidate is "format string", and we already use that for the older types of format strings.  If those were to fall out of use, I'd expect "format string" to come to mean what f-string does now.  But by the time that happens, f-string will be more entrenched than it is now.  We could try for "format expression", but that is more syllables, and faces headwind because the f prefix obviously makes it a "string"-like object, and that's how we think about it: a string with expressions inside it, instead of as an expression itself.

In summary, I think we're stuck with f-string.  It's a term of art: a short expression that encapsulates a non-trivial concept for which there are no precise existing words.

The abstract of PEP 498 states:
```
In this PEP, such strings will be referred to as "f-strings", taken from the leading character used to denote such strings, and standing for "formatted strings".
```

I think we're getting bogged down in a larger scope than this issue is about. All we should be discussing in this issue is whether adding an entry in the glossary for "f-string" as it's already being used in the community is bad (which I don't think it is since it's seeing use "in the wild"). No one is suggesting we change all the documentation to start using the shorthand/slang term, nor to introduce entries for other types of string literals where the community has not started using such terms (e.g. r-strings for raw strings). Heck, the docs already use "f-string" internally as a link target, i.e. https://docs.python.org/3/reference/lexical_analysis.html#f-strings (notice the intra-page link target).

IOW this is just making it easier for someone who comes across the term "f-string" to know what it means when they see it on e.g. Twitter, not trying to come up with a more accurate shorthand.

Agreed with Brett.  What I was trying to say was that we aren't going to get people to change to a different term, nor are the other 'x-string' abbreviations interesting, so we should document just f-string. But I wasn't exactly clear that that was my point :).

I was probably misunderstood, too, in hindsight, it's my fault for not being more clear :-). 

In my first sentence I was merely pointing out the oddity of <prefix>-string not being a very popular term until f-string came along.

As for my second sentence (adding the other prefixed strings to the glossary) I was thinking of using the names people currently use. Entries for (byte|raw|unicode)-strings, seeing as they don't already exist, might be a good addition now that f-strings are up for inclusion.

Since this ticket is about adding f-strings to the Glossary, let's keep this as discussions about the inclusion of f-strings in the Glossary.

If others want to add (byte|raw|unicode)-strings into the Glossary, they can open another ticket. 

Thanks :)

P.S: I like David's quote "..f-string. It's a term of art"

Completely agree, Mariatta. I just wanted to clarify my initial position :-)

New changeset 33db068dac7686e37736f7ecf8abb2aee0345cf2 by Mariatta in branch 'master':
bpo-29928: Add f-string to the Glossary (GH-864)
https://github.com/python/cpython/commit/33db068dac7686e37736f7ecf8abb2aee0345cf2

New changeset 7b5b1379ac2c1e89ebf90b88b5d32457910e975e by Mariatta in branch '3.6':
bpo-29928: Add f-string to the Glossary (GH-864) (GH-914)
https://github.com/python/cpython/commit/7b5b1379ac2c1e89ebf90b88b5d32457910e975e

Thanks all!