By definition identity checking is the finest-grained distinction you can make between things. If two things are identical, they can't possibly be different in any way. This is what philosophers call the “indiscernibility of identicals”, and, if it sounds like a tautology, it's because it is!
> By definition identity checking is the finest-grained distinction you can make between things.
Yes, but there are different identities. "is" implements storage identity checking between python objects (a term broader than the sense in which you use "objects", which includes both what you call "objects" and representations of values).
Logical identity checking between Python values (as well as object equivalence, but not identity, checking between Python "objects" in the sense you use the term) is done by "==".
For most python value representations, the relationship between storage identity of the representation and logical identity of the value is undefined.
> which includes both what you call "objects" and representations of values
This is exactly what I'm saying is wrong: branching on the representations of values.
> For most python value representations, the relationship between storage identity of the representation and logical identity of the value is undefined.
> This is exactly what I'm saying is wrong: branching on the representations of values.
Well, yes, its wrong in that (except in the cases where value identity and representation storage identity are guaranteed to be equivalent) you generally shouldn't do it (the exception being if you are building code to do something oomphaloskeptic where the purpose of code is to answer questions about what its own implementation is doing.)
But the fact that doing that is possible in Python does not change the fact that Python does, in fact, support values (including compound values) with value-oriented semantics.
> If it's undefined, then how come I can query it?
The relation between physical identity of the storage representations and logical identity of the values they represent is undefined by the language specification.
At runtime, every representation of a value has some storage identity, and you can query the relationship between that and the storage identity of another representation of a value. But the answer you get has no guaranteed correlation to whether the values represented by those representations are the same value (which you can also query.)
> Well, yes, its wrong in that (except in the cases where value identity and representation storage identity are guaranteed to be equivalent) you generally shouldn't do it
A language's semantics doesn't tell me what I “should” do. It tells me what I can do, and what other people who write code that interacts with mine can do.
> At runtime, every representation of a value has some storage identity
Not in the semantics of the source language. Value representations are purely an implementation artifact.
> By definition identity checking is the finest-grained distinction you can make between things
By your definition, perhaps. The rest of us don't always use the word "identity" with this meaning. And since you don't own the English language, you don't get to tell the rest of us how to use words.
> If two things are identical, they can't possibly be different in any way.
Then by your definition, two Python tuples (1, 2, 3) are not identical. Which says absolutely nothing about how I can write programs using them, or what concepts of "identity" the operators in those programs can implement.
> This is what philosophers call...
We're talking about programming here, not philosophy.
> I can write a program that treats all Python objects identically, by simply doing nothing. That doesn't make all Python objects actually identical.
Yes, you can. Thank you for proving my point that Python programs don't have to use your definition of identity.
But that's a silly example. Here's an example that's not silly: in an earlier discussion you said dictionary keys have to be values--which would imply that dictionary key lookup must use your concept of "identity", so only two objects that are identical by your definition will behave as identical keys in a dictionary. But two distinct Python tuples (1, 2, 3), which are not identical by your definition, do behave as identical keys in a Python dictionary. In other words, Python dictionary key lookup does not use your concept of "identity".
To everyone else, this means your concept of identity is simply not relevant. To you, it appears to mean that Python is violating Western logic.
> Programming is applied logic, which is a branch of philosophy.
To you, perhaps. Not to me. And not, I suspect, to most of the other programmers in this discussion.
> But two distinct Python tuples (1, 2, 3), which are not identical by your definition, do behave as identical keys in a Python dictionary.
The numbers 2 and 4 behave identically when passed to a function that tests whether its argument is an even number. Are 2 and 4 identical now?
> To you, it appears to mean that Python is violating Western logic.
This is the third time I'm saying I never said Python is violating Western logic. It's like saying I made a machine that violates gravity - it's literally impossible! Python just doesn't have compound values.
> The numbers 2 and 4 behave identically when passed to a function that tests whether its argument is an even number. Are 2 and 4 identical now?
They are with respect to the even/odd property. So if that's the property I'm interested in, they're identical. They might not be if I'm interested in some other property.
In other words, as dragonwriter has already pointed out, there is more than one concept of identity.
There's only one: Two entities are equal if nothing can distinguish them. This is the “identity of indiscernibles”.
In a language with abstract data types, such as Standard ML, you could define a new type whose internal representation is an integer, but which provides no operations that would distinguish between two even or two odd numbers. But Python doesn't have this.
>There's only one: Two entities are equal if nothing can distinguish them. This is the “identity of indiscernibles”.
This doesn't exist. If you can distinguish past and present, you can distinguish anything by time. An object in one moment is not identical to an object in another moment because the moment changed? No. You have to decide on what invariants you care about to have a consistent notion of identity. Yours is inadequate to do anything, as you demand the whole universe be invariant in all aspects; such a thing is trivial and vacuous. And it surely is not the structure encoded in any usage of the term "identity", as that word has non-trivial structure.
> If you can distinguish past and present, you can distinguish anything by time.
That's the thing: Objects exist in time. Values don't. Values exist in the language's semantics, which is a timeless mathematical object. Does it make sense to ask when the number 2 suddenly came into existence?
> An object in one moment is not identical to an object in another moment because the moment changed? No. You have to decide on what invariants you care about to have a consistent notion of identity.
You're confusing “identity of indiscernibles” with “indiscernibility of identicals”.
And, obviously, you can't use the temporal properties of objects to determine whether their atemporal identities are equal.
> Yours is inadequate to do anything, as you demand the whole universe be invariant in all aspects; such a thing is trivial and vacuous.
Nope. It just requires you to distinguish between things that exist in time and things that exist independently of time.
What you've implemented isn't an abstract type. You can inspect the internal representation anytime, distinguishing between things that were meant never to be distinguished.
