At 15:33 19.03.2004 -0500, Andrew Koenig wrote: > > Okay, but I don't see why that implementation detail is important. > >It is important because it causes programs to behave differently on >different implementations. > > > > So what I'm claiming is that there should be a way of asking: Given two > > > objects, is there any way to distinguish them aside from their identity? > > > Why do you need to ask that question? Further more, why is it > > important enough to require a builtin operator? > >It certainly doesn't *require* a builtin operator. I do think, however, >that the proposed comparison is more useful than "is" in most contexts in >which programmers use "is" today. In particular, programs that use "is" can >easily contain bugs that testing on a particular implementation can never >reveal, and using the proposed comparison instead makes such bugs much less >likely (and perhaps even impossible). maybe, OTOH I suspect that people most puzzled by >>> a = 1 >>> b = 1 >>> a is b True >>> a = 99 >>> b = 99 >>> a is b True >>> a = 101 >>> b = 101 >>> a is b False really simply expect there to be just one 1 and 99 and 101, not an half-a-page definition of 'is' or some such involving the notion of (im)mutability.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4