why () is () and [] is [] work in other way?

[Devin Jeanpierre]

On Mon, Apr 23, 2012 at 3:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> Bollocks it's well defined. We've already agreed that "1 is 1" may or
>> may not return True.
>
>
> 'We' have not so agreed. The function should tell the truth. Let me repeat:
> 'is' is a function whose two inputs are not eternal mathematical values but
> rather are computational implementation objects with finite lifetimes.

Er, well, no. I'm willing to concede that I was wrong for being so
eager to say "y'all are wrong". I was, I misunderstood the objection
you and Steven were making, which is that "is" is well-defined, but
object identities are not.

However, you appear to be trying to shift the goalposts. Either "1 is
1" is always True, or always False, or sometimes one or the other. If
I'm mistaken and it so happens that numeric constants are guaranteed
somewhere to always be cached, then replace it with the empty tuple.
It is a fact that the result is not always the same, and you're trying
to dodge around that. :/

> It is wrong to interpret the Python expression '1 is 1' as a mathematical
> expression. It simply is not such. Trying to do so only leads to confusion,
> as this thread show.

Of course it's a mathematical expression. There's a very well
researched theory of computation that links Python all the way to
abstract purely-functional calculi, allowing us to mathematically
model everything.

But if you mean, "this isn't like high school arithmetic", sure. It
depends on a lot more than these things usually do (you say it depends
on time, but in the simple cases above, it depends on how number
objects and tuple objects are created.)

> The 'is' function answers a question about the current state of a particular
> temporal computational process. Its output is well-determined given its
> actual input. Like other introspection functions, it is useful for testing
> an implementation.

Sure, I understand this now. I am a bit regretful, the discussion of
whether "is" itself is ambiguous, or the actual values, doesn't really
matter. What matters is that sometimes "() is ()" will return True,
and sometimes it will return False. It doesn't really matter whether
it's "is" that's ambiguous, or the identity of newly made tuples. The
point is that something is ambiguous. And maybe that's worth changing?

-- Devin