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

[Adam Skutt]

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.

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.

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.  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.

Adam