Reference/Expressions/Primaries: "Primaries represent the most tightly
bound operations of the language. Their syntax is:
primary ::=  atom | attributeref | subscription | slicing | call"

This (along with the fact that all sections after 'call' doc follow in
order of decreasing precedence) implies to me that atom is highest and
call is lowest of this group.  Certainly, attributeref seems higher than
those that follow, as ob.attr[x] and ob.attr(x) are executed as
(ob.attr)[x] and (ob.attr)(x), not as ob.(attr[x]) or ob.(attr(x)) (both
taken literally are syntax errors). (Michael Tobis gave an example today
on c.l.p showing this.)

But the Summary of precedence at the chapter end lists attriburef to
call as low to high.  I think these should be reversed.

Thanks, moved attribute reference to the appropriate place in r65693.

I am reopening because my suggested fix was wrong. As pointed out by
Fredrik Lundh on PyDev the next day, quoting from the grammar,
attributes, subscriptions, slicing, and call have the *same* precedence.
 I thought I posted his comment and an correct fix, but it is not here,
so here it is again, with additional needed fixes revealed by another
post in c.l.p.  The problem is that the table has three (not just one)
groups of equal precedence entries on multiple lines.  And power has
mixed precedence.

Suggestions (low to high as in the table):

Comparisons section
"all comparison operations in Python have the same priority, which is
lower than that of any arithmetic, shifting or bitwise operation."

In the table, before the "in" line, add
"[Next 3 lines indicate same precedence]            Comparisons"
Then indent both the operator and description entries on the next three
lines, and for the third, change "Comparisons" to "Order and equality
tests". Inclusion and identity tests are comparisons also.

Retitle section "Unary arithmetic operations" to "Unary arithmetic and
bitwise operations" and change the following sentence
"All unary arithmetic (and bitwise) operations have the same priority:"
to 
"All unary arithmetic and bitwise operations have the same priority:"
The parentheses could lead one to not understand that 'unary' applies to
bitwise as well as arithmetic.  (Which is to say, I was initially
confused ;-).

Then combine the corresponding lines in the table to make
+x, -x, ~x                  Positive, negative,  bitwise not

Primaries section:
"Primaries represent the most tightly bound operations of the language.
Their syntax is:
primary ::=  atom | attributeref | subscription | slicing | call"

Fredrik quoted the following from the grammar
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME

and this from the TEX version of the docs:
"  \hline
    \lineii{\code{+\var{x}}, \code{-\var{x}}}    {Positive, negative}
    \lineii{\code{\~\var{x}}}            {Bitwise not}
  \hline
    \lineii{\code{**}}                {Exponentiation}
  \hline
    \lineii{\code{\var{x}.\var{attribute}}}    {Attribute reference}
    \lineii{\code{\var{x}[\var{index}]}}    {Subscription}
    \lineii{\code{\var{x}[\var{index}:\var{index}]}}    {Slicing}
    \lineii{\code{\var{f}(\var{arguments}...)}}    {Function call}
  \hline
  ...
which indicates that the author intended "." and "[" to appear in the
same box, but got overruled by the Tex->HTML conversion tool. " 

The overruling happened at least back to the 2.4 docs.
 
So I suggest
"[Next 4 lines indicate same precedence]                  Trailers" 
with indents as before.

An alternative to the added line and indent fix would be to remove the
lines between things of equal precedence.  The suggested text changes,
including the one to 'Comparisons' in the table, would still remain.

Since the last three entries in the table are all atoms, it is possible
that they also have the same precedence with respect to each other
(Fredrik did not quote any more of the TEX source), though it is a moot
point I think because of the required nesting.

Last issue (I hope): "The power operator binds more tightly than unary
operators on its left; it binds less tightly than unary operators on its
right."

To be exactly correct, 'arithmetic and binary' should modify 'unary'
since there is also unary logical operator not, and ** does *not* bind
less tightly that 'not' on its right.  An expression like "2 ** not 1"
has been parsed as "2 (** not) 1",  a syntax error, probably forever and
certainly in 2.2 before bools up to 3.0, and not as "2 ** (not 1)",
which is 1 even in 3.0.

Also, the table really needs two ** lines:
** [followed by +,-,~]            Exponentiation
** [othewise]                     Exponentiation
before and after the unary +,-,~ line or lines, in that order.

I will review the patch if you post it.  I will otherwise try to take a
look when it comes out.

Fixed in r69769.