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

[Kiuhnm]

On 4/22/2012 21:43, John Nagle wrote:
> On 4/20/2012 9:34 PM, john.tantalo at gmail.com wrote:
>> On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:
>>
>>> I believe it says somewhere in the Python docs that it's undefined and
>>> implementation-dependent whether two identical expressions have the same
>>> identity when the result of each is immutable
>
> Bad design. Where "is" is ill-defined, it should raise ValueError.
>
> A worse example, one which is very implementation-dependent:
>
> http://stackoverflow.com/questions/306313/python-is-operator-behaves-unexpectedly-with-integers
>
>
>  >>> a = 256
>  >>> b = 256
>  >>> a is b
> True # this is an expected result
>  >>> a = 257
>  >>> b = 257
>  >>> a is b
> False
>
> Operator "is" should be be an error between immutables
> unless one is a built-in constant.
[...]

I can't think of a single case where 'is' is ill-defined.
You're blaming 'is' for revealing what's really going on. 'is' is /not/ 
implementation-dependent. It's /what's going on/ that's 
implementation-dependent.
"a is b" is true iff 'a' and 'b' are the same object. Why should 'is' 
lie to the user?
It does exactly what it says it does: it tells the user whether two 
objects are the same.
In C++, for greater efficiency, two objects are compared for equality by 
first checking their addresses and then their contents. 'is' would be 
perfect for that.

What I don't like is 'isinstance'. I'd prefer an infix operator 'isa' or 
'is_a'.

Kiuhnm