Reference

[Steven D'Aprano]

On Tue, 04 Mar 2014 21:47:21 -0800, Rustom Mody wrote:

> 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

What you are describing is normally called the implementation and the 
interface.


> 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'

Only if you wish to ignore the standard terminology used by the rest of 
the computing world, and furthermore re-define the term "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.

This doesn't seem to be relevant.


> 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.

And this appears to be meaningless. The best I can come up with is that 
you're concerned about the philosophical implications of stating that 
object x is object y.

Quite frankly, I think that's silly. Such concerns about identity of 
physical entities in the real world are *irrelevant*. You seem to be 
making a category mistake: the word "is" has certain meanings in plain 
English, with associated philosophical problems, therefore the Python 
"is" operator must have exactly the same meanings and problems. But this 
is as silly as thinking that we should be able to use a computer file to 
cut through metal, or that equality between 1+1 and 2 is a question of 
human rights.

The "is" operator has a well-defined meaning in Python. The "axe of my 
grandfather" paradox does not apply to the "is" operator. That definition 
in Python is very simple: the "is" operator returns True if the two 
operands are the same object, and false if they are different objects.

> 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 ==

There is no discrepancy between "is" and ==, since they are different 
operators with different semantics. You might as well claim that there is 
a discrepancy between + and * because 5+7 and 5*7 return different 
answers.


>> 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. 

I'd rather you answer the questions I asked rather than change the 
subject to an irrelevance.

[...]
> Decide the viewpoint  -- choose the appropriate equivence predicate No
> claim even remotely to having a clue to metaphysical being that python's
> 'is' implies

There is no metaphysical implication from Python's "is" operator. If the 
operator had precisely the same behaviour, but was called "same", as in:

a same b
=> returns True if a and b are the same object
=> returns False if a and b are not the same object

would you claim there was a metaphysical implication?

How about if it were called "eq", like Lisp uses?



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/