Expressions mentions "tuple displays" in 6.16 (Operator precedence).

AFAIK, there ano "tuple displays". Expressions mentions list, dict, and set displays, and then talks about generator expressions.

I guess "parenthesized expressions" should be the term that fits here?

Nope, a tuple display is not equal to a parenthesized list.  For example, in:

   x = 1, 2, 3

1, 2, 3 is a tuple display.  The parenthesis are optional in that case (in the general case it is the comma that makes the tuple, not the parens).

However, as far as I can see that's the only mention of "tuple display" in the docs, which makes the doc you reference less than useful to a reader that doesn't know what it means.

Actually, 'tuple display' is in the index under 'display' and links to the last paragraph in 6.2.3.  However, except for the index name, that paragraph doesn't use the phrase 'tuple display'.  So it gives the definition without saying what it is defining.

> Note that tuples are not formed by the parentheses, but rather by use of the comma operator. The exception is the empty tuple, for which parentheses are required — allowing unparenthesized “nothing” in expressions would cause ambiguities and allow common typos to pass uncaught.

The thing is that "tuple displays" like:

nums = (n for n in range(10))

Yield a generator expression instead of a tuple.

Also, unparenthesized "tuple displays" like 1, 2, 3 can't be used in expressions, AFAIK:

>>> if 3 == 1, 2, 3:
SyntaxError: invalid syntax

So, you end up using parenthesized expressions (that may or may not shield tuples) to use tuples in expressions. So talking about "tuple expressions" in the operator precedence table doesn't make much sense to me :/

Also, if a "tuple display" doesn't yield a tuple, should it be named a "tuple display" after all?

Ignore the previous comment.

The thing is that "tuple displays" like:

nums = (n for n in range(10))

Yield a generator expression instead of a tuple.

Also, unparenthesized "tuple displays" like 1, 2, 3 can't be used in expressions, AFAIK:

>>> if 3 == 1, 2, 3:
SyntaxError: invalid syntax

So, you end up using parenthesized expressions to use tuples in expressions. So talking about "tuple displays" in the operator precedence table doesn't make much sense to me :/

Also, if a "tuple display" doesn't yield a tuple, should it be named a "tuple display" after all?

That's a generator expression, just like [x for x in ramge(3)] is a list comprehension, not a list display.  And yes, in a number of circumstances parenthesis are required to delimit the tuple display and disambiguate the syntax.  That is, it is the 1, 2, 3 that is the tuple display, but sometimes you have to enclose it in parenthesis in order for the parser to recognize it.  Which is why it would be good to give a more thorough explanation of what a tuple display is than the unlabeled one Cheryl pointed out.  I'm not entirely sure what the exact rules are for when you get a syntax error without the parens, myself :)

The documentation says a display may or may not have a comprehension :/

[1, 2, 3] is a list display too.

[x for x in range(3)] is a display that has a comprehension. Acoording to the doc.

Hmm.  OK, I didn't think that's how we'd defined those terms, but then I don't actually work with the parser much myself :)  However, generator expressions are clearly called out as a separate thing.  All of the other display types get their own section, so I would think tuple display should too if it really is a syntax unit...but maybe it isn't.

Also, I'm not clear on what 'binding' means in that table entry.

I see now why you wanted to say "parenthesized expression", but as far as I can see the previous text is referring to it as an expression list in parenthesis form.  That's a bit wordy, which may be why someone used tuple display there.  Clearly there is some ambiguity here that it would be nice to resolve, considering this is part of the language spec, but frankly I'm not sure what to suggest.  At that level I'm not sure how the "operator precedence" is actually "resolved"...I think it is more a matter of it being implicit in the parsing, but I'm not sure.  Like I said, not my area of expertise.

I'm restoring the original title since we are not sure it was incorrect after all.

I have also updated the PR to remove the tuple display entry from the index.

New changeset dc269971091710563a0d730a0d4b084901826c15 by Miss Islington (bot) (Andre Delfino) in branch 'master':
bpo-33459: Fix "tuple displays" term in Expressions.rst (GH-6760)
https://github.com/python/cpython/commit/dc269971091710563a0d730a0d4b084901826c15

New changeset 4c2fa5c474af81487c7a8d4188f9afd80d4d769b by Stéphane Wirtel (Miss Islington (bot)) in branch '3.7':
bpo-33459: Fix "tuple displays" term in Expressions.rst (GH-6760) (GH-15939)
https://github.com/python/cpython/commit/4c2fa5c474af81487c7a8d4188f9afd80d4d769b

New changeset 4d2babd99022bf43dc659d9fe5700c1fc13808c4 by Stéphane Wirtel (Miss Islington (bot)) in branch '3.8':
bpo-33459: Fix "tuple displays" term in Expressions.rst (GH-6760) (GH-15940)
https://github.com/python/cpython/commit/4d2babd99022bf43dc659d9fe5700c1fc13808c4