Reference

[Rustom Mody]

On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:

> > Python's 'is' leaks
> > the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> > it illegitimately

> and then later in another post:

> > "is" in python leaks machine representations
> > into the otherwise clean HLL abstraction in python

> Rather than respond with incredulity and declare that you have no idea 
> what you are talking about, I'll give you the benefit of the doubt, and 
> accept the possibility that I am wrong, or possibly misunderstanding you.

Umm...
I guess my language was sloppy (a bit)
A machine is ultimately also an abstraction --
What is firmware/microcode? Is it a virtual machine? etc
Lets leave that however and just take 'machine' as a given.

Using machines as given, we build reprs for our (programmer's) data structures

So data structures are abstractions that have two 'faces' -- 
the machine-facing and the programmer-facing

For clarity of expression (and where you perhaps found me sloppy?? not sure...)
its best to call the machine-face 'a representation' and the programmer-face
'an abstraction'

Clearly this is a programmer-biased viewpoint. A hardware engineer would see
things differently. As would the user of the app the programmer programs.

Which is why to use the locution "is" without appropriate framing is philosopical
is a pretension to a 'God's-eye-view'.
If you are privy to such a viewpoint I'd be interested to know
But for the rest of us who are not, its good to remember there are only
perspectives no absolute truth.

That python is a hll means that machine reprs are intended to be abstracted
away. 'is' fails to do that -- proof of that being the discrepancy between
is and ==

> Can you explain what machine representations are leaked into Python by 
> the is operator?

> Do you see this as an accident of implementation, a bug that might be 
> fixed, or a misfeature that was deliberately designed?

> Can you elaborate on why id() is legitimate and "is" is not?

Let me talk of Lisp which is IMHO more philosophically sane.
Lisp has eq eql equal and a few type-specific others such as = for numbers
string-= for strings etc

eq is roughly python's 'is'
equal is roughl python's ==
The type-specific ones error out rather than returning false for out-of-bounds types.

So much for the technology

Now to the philosophy behind it:
Decide the viewpoint  -- choose the appropriate equivence predicate
No claim even remotely to having a clue to metaphysical being that python's 'is' implies