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

[Kiuhnm]

On 4/26/2012 16:00, Adam Skutt wrote:
> On Apr 26, 9:37 am, Kiuhnm<kiuhnm03.4t.yahoo.it>  wrote:
>> 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?
>
> There are a lot of misfeatures in Java.  Lack of operating overloading
> really isn't one of them. I prefer languages that include operator
> overloading, but readily understand and accept the arguments against
> it.  Nor is the differing behavior for '==' between primitives and
> objects a misfeature.

The fact that you think that that's "differing behaviour" is what makes 
it a misfeature. The fact that you think that '==' can take objects as 
operands confirms that Java *does* confuse programmers.

> C# and Python do have a misfeature: '==' is identity comparison only
> if operator== / __eq__ is not overloaded.  Identity comparison and
> value comparison are disjoint operations, so it's entirely
> inappropriate to combine them.

They're not "disjoint", in fact one almost always implies the other (*).
Python's idea is that, by default, any object is equal to itself and 
only itself. The fact that this is equivalent to "identity comparison" 
is just a coincidence, from a conceptual point of view.
(*) nan == nan is false, but, at least conceptually, a 'NotComparable' 
exception should be raised instead. That wouldn't be very useful, though.

> I don't necessarily mind if the two operations have the same symbol,
> as long as there's some other way in-context to determine which
> operation is occurring.  This is the case in C and C++, for example.
>
>> Python's way is much much cleaner.
>
> Nope. Automatically substituting identity equality for value equality
> is wrong.  While rare, there are legitimate reasons for the former to
> be True while the latter is False.

There shouldn't be, to be fair.

>  Moreover, it means that class
> authors must remember to write an __eq__ when appropriate and won't
> get any sort of error when they forget to do so.  That can lead to
> bugs.

I can agree on that, but that's something you can solve with a minor 
modification to the language. What I was talking about is the core 
design of Java and Python.

Kiuhnm