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

[Kiuhnm]

On 4/26/2012 13:45, 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.

Why should we take from Java one of its worst misfeatures and disfigure 
Python for life?
a==b compares references while a.equals(b) compares values. Really??? 
Come on...
Python's way is much much cleaner.

Kiuhnm