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/ -- https://mail.python.org/mailman/listinfo/python-list
