Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <python-python-list@m.gmane.org>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.002
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'programmer': 0.03; 'operator': 0.03; 'practice,': 0.07; 'referring': 0.07; 'abstraction': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'python': 0.11; 'coincide': 0.16; 'compares': 0.16; 'finney': 0.16; 'leaks': 0.16; 'objection': 0.16; 'received:80.91.229.3': 0.16; 'received:plane.gmane.org': 0.16; 'summarizes': 0.16; 'differ': 0.19; "python's": 0.19; 'things.': 0.19; 'machine': 0.22; 'memory': 0.22; 'header:User-Agent:1': 0.23; 'references': 0.26; 'post': 0.26; 'values': 0.27; 'header:X-Complaints-To:1': 0.27; "doesn't": 0.30; 'code': 0.31; 'location,': 0.31; 'writes:': 0.31; 'not.': 0.33; 'equal': 0.35; 'no,': 0.35; 'but': 0.35; 'there': 0.35; 'received:com.au': 0.36; 'view,': 0.36; 'so,': 0.37; 'ben': 0.38; 'same.': 0.38; 'to:addr:python-list': 0.38; 'fact': 0.38; 'does': 0.39; 'itself': 0.39; 'legitimate': 0.39; 'to:addr:python.org': 0.39; 'either': 0.39; 'received:org': 0.40; 'how': 0.40; 'is.': 0.60; "you're": 0.61; 'guarantee': 0.63; 'happen': 0.63; 'skip:\xe2 10': 0.65; 'promise': 0.68; '8bit%:46': 0.78; 'received:125': 0.84; 'constitute': 0.93
X-Injected-Via-Gmane: http://gmane.org/
To: python-list@python.org
From: Ben Finney <ben+python@benfinney.id.au>
Subject: Re: Reference
Date: Wed, 05 Mar 2014 15:32:16 +1100
References: <53144e8d$0$2149$426a74cc@news.free.fr> <1d1dfa1b-b715-4d8f-9c12-f0d3dc1a22c9@googlegroups.com> <85ppm3httu.fsf@benfinney.id.au> <lf2sjk$7d4$1@ger.gmane.org> <20140303155112.46e34ff8@bigbox.christie.dr> <mailman.7666.1393884138.18130.python-list@python.org> <87siqy7whs.fsf@elektro.pacujo.net> <53155c15$0$2923$c3e8da3$76491128@news.astraweb.com> <mailman.7693.1393910647.18130.python-list@python.org> <op.xb75g7ap5079vu@gnudebeest> <roy-A9E76C.21091704032014@news.panix.com> <164d209c-ba5e-449f-bc25-c27ebfb1fc0f@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Gmane-NNTP-Posting-Host: vmx15867.hosting24.com.au
X-Public-Key-ID: 0xBD41714B
X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F  520C B7AC 2E51 BD41 714B
X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc
X-Post-From: Ben Finney <bignose+hates-spam@benfinney.id.au>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Cancel-Lock: sha1:o35oiYmixFvtbGqS7kYb4NgUYzo=
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.7791.1393993951.18130.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1393993951 news.xs4all.nl 2867 [2001:888:2000:d::a6]:35351
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:67799

Rustom Mody <rustompmody@gmail.com> writes:

> * ... which summarizes my objection in this thread:

Your long post references many things. Which is the “which” to which you
refer? What is it you're referring to that summarises your position?

> Python's 'is' leaks the machine abstraction.

No, it does not. The ‘is’ operator compares object identity, which is
itself an abstraction. What is leaking?

Note that the “location of the object in memory” is not a guarantee made
by either Python's object identity nor the ‘id’ function. There's no
need to treat “object location in memory” as equal to “object identity”,
and code which makes that assumption is buggy. The documentation doesn't
promise they will be the same.

So, the fact that some Python implementations happen to present
‘id(foo)’ values that coincide with a representation of memory location,
does not constitute a leaky abstraction: there is no need for any Python
programmer to care about what the memory location is. So if that's the
basis of your objection, I don't consider that objection to be
legitimate.

> 'id' does it legitimately (somewhat), 'is' does it illegitimately

What would, in your view, be a legitimate way for Python to present
object identity to the programmer? How would it differ substantially
from Python's existing abstraction of object identity?

-- 
 \          “That's all very good in practice, but how does it work in |
  `\                                             *theory*?” —anonymous |
_o__)                                                                  |
Ben Finney