Section 5.9 of the LRM specifies that 'in' and 'is' are 
treated the same as '=='. However, the priority chart in 
the 5.14 Summary part of chapter 5 gives them different 
priorities. This leads one to expect that 'a' in 'abc' == 1 
should parse as if it was 'a' in ('abc' == 1) while it 
actually parses as ('a' in 'abc') == 1. 

The priority chart in the LRM should be corrected to put 
both 'is' and 'in' on the same line with the other 
conditionals. It would also be nice if a note pointed out 
that all of the operators on this line exhibit short circuit 
behavior, and also that this is not a change from prior 
releases.

See the discussion on c.l.py beginning on 10/30/2003 
titled Boolean Confusion. The first post is by Frantisek 
Fuka.

I've put it under 2.2.3 only because I don't have the 
2.3.2 manual to hand. I believe the original report on 
c.l.py was under 2.3.2

John Roth

Logged In: YES 
user_id=60314

The latex source code for the priority chart is clearly coded with the intention of having tests and comparisons in the same box (there is just one \hline tag before and one after them all) but the latex->html formatting does not follow this intention (and does put each into a visually separate "box", leading to the possible confusion).  As a fix, I have clarified the previously rather elliptical text just before the table, explicitly reminding the reader that comparisons _and tests_ all have the same priority, and all chain, and inserting a reference to 5.9 in lieu of the previous vaguer "see above".  The reminder about short-circuiting here is unwarranted -- indeed it's not even given for 'and' and 'or' -- as this table is about syntax, not semantics -- so I have not inserted it as suggested; the explicit pointer to 5.9 should take care of that.

Attached see the context-diff file ref5.diff; I have also committed the change (on the 2.3 maintenance branch of the CVS sources, only).

Logged In: YES 
user_id=6656

Alex, I think as a point of principle checking things in to
the maintenence branch *only* is a bad idea.  Changes
generally filter from trunk to release branch, not the other
way round.  Would it be terribly hard for you to make all
your weekend checkins on the trunk, too?