steve+comp.lang.python at pearwood.info
Wed Mar 5 19:19:25 CET 2014
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
> 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
> 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
> 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
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
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
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
>> 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?
More information about the Python-list