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