This patch, made against svn revision 42105, adds
caveats to Doc/ref/ref3.tex concerning the use of the
is operator in conjunction with class- and
instance-methods.

As I was recently bitten by trying to do the equivalent of
"""
>>> MyClass.a_class_method is MyClass.a_class_method
False
>>>
"""
I thought the manual might benefit from coverage of
this as-yet-undocumented area.

Logged In: YES
user_id=6656

I'm not really sure this patch is a good idea. It seems over-specific to one
particular pitfall. Maybe instead warning stickers should be attached to the
description of the 'is' operator.

Logged In: YES
user_id=1344176

I'm not sure a full-blown caveat on is is a good idea,
unless this particular issue impacts areas beyond
{class,instance}methods (the only two places I've see it).
However, tacking a note to is, something like "you may
notice unusal behaviour in certain combinations of is and
class- and instancemethods; see their docs for more info",
would probably be a good idea.

I tried to make the original doc patch as specific as
possible because it's a tricky problem. There's a good
explanation for the following behaviour, but until someone
expalins it to you, you're probably going to think it's a bug.
"""
>>> id(MyClass.class_method) == id(MyClass.class_method)
True
>>> MyClass.class_method is MyClass.class_method
False
"""

An even more surprising example:

>>> id([1]) == id([2])
True

The example sure is surprising for somebody without intimate knowledge
about Python's memory management. Although the is operator is
implemented as id(a) == id(b) reference counting, free lists and arenas
can cause some surprising effects.

I agree it's not a good idea to be too much specific about this. The
patch attached adds the following footnote to the 'is' operator:

Due to automatic garbage-collection, free lists, and the dynamic nature
of descriptors, you may notice unusual behaviour in certain combinations
of :keyword:`is` operator, like those involving identity comparisons
between class and instancemethods, and free instances in the same
expression. Check their docs for more info.

Reworded a bit and applied as r64638.