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

[John Nagle]

On 4/26/2012 4:45 AM, Adam Skutt wrote:
> On Apr 26, 1:48 am, John Nagle<na... at animats.com>  wrote:
>> On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
>>
>>> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>>
>>>> Though, maybe it's better to use a different keyword than 'is' though,
>>>> due to the plain English
>>>> connotations of the term; I like 'sameobj' personally, for whatever
>>>> little it matters.  Really, I think taking away the 'is' operator
>>>> altogether is better, so the only way to test identity is:
>>>>       id(x) == id(y)
>>
>>> Four reasons why that's a bad idea:
>>
>>> 1) The "is" operator is fast, because it can be implemented directly by
>>> the interpreter as a simple pointer comparison (or equivalent).
>>
>>      This assumes that everything is, internally, an object.  In CPython,
>> that's the case, because Python is a naive interpreter and everything,
>> including numbers, is "boxed".  That's not true of PyPy or Shed Skin.
>> So does "is" have to force the creation of a temporary boxed object?
>
> That's what C# does AFAIK.  Java defines '==' as value comparison for
> primitives and '==' as identity comparison for objects, but I don't
> exactly know how one would do that in Python.

    I would suggest that "is" raise ValueError for the ambiguous cases.
If both operands are immutable, "is" should raise ValueError.
That's the case where the internal representation of immutables
shows through.

    If this breaks a program, it was broken anyway.  It will
catch bad comparisons like

     if x is 1000 :
	...

which is implementation dependent.

				John Nagle