classification
Title: Add notes to the manual about `is` and methods
Type: enhancement Stage:
Components: Documentation Versions: Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: amaury.forgeotdarc, christian.heimes, collinwinter, fdrake, georg.brandl, mwh, werneck
Priority: normal Keywords: easy, patch

Created on 2006-01-20 12:39 by collinwinter, last changed 2008-07-01 20:50 by georg.brandl. This issue is now closed.

Files
File name Uploaded Description Edit
ref3.tex.diff collinwinter, 2006-01-20 12:39 Patch to Doc/ref/ref3.tex, r42105
issue1410739.patch werneck, 2008-05-10 18:35 Patch to Doc/reference/expressions.rst
Messages (7)
msg49355 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-01-20 12:39
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.
msg49356 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2006-01-21 10:46
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.
msg49357 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-01-21 15:33
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
"""
msg61910 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-01-31 17:16
An even more surprising example:

>>> id([1]) == id([2])
True
msg61911 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-31 17:21
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.
msg66555 - (view) Author: Pedro Werneck (werneck) Date: 2008-05-10 18:35
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.
msg69075 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-07-01 20:50
Reworded a bit and applied as r64638.
History
Date User Action Args
2008-07-01 20:50:15georg.brandlsetstatus: open -> closed
resolution: fixed
messages: + msg69075
2008-05-27 06:55:23georg.brandlsetassignee: georg.brandl
nosy: + georg.brandl
2008-05-10 18:35:17wernecksetfiles: + issue1410739.patch
nosy: + werneck
messages: + msg66555
2008-01-31 18:12:51christian.heimessetkeywords: + easy
assignee: fdrake -> (no value)
type: enhancement
versions: + Python 2.6, - Python 2.4
2008-01-31 17:21:41christian.heimessetnosy: + christian.heimes
messages: + msg61911
2008-01-31 17:16:24amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg61910
2006-01-20 12:39:49collinwintercreate