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

[Adam Skutt]

On Apr 26, 12:02 pm, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> 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:
> >>>>       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.
>

The equality operator can absolutely be used between two objects.  Try
it if you don't believe me.  It always does identity comparison when
given two objects. It can also be given two primitives, and in this
case, it does value comparison.  Despite performing different
operations with the same symbol, there's little risk of confusion
because I can trivially figure out if a variable is an object or an
primitive.

> > 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 (*).

"Almost always" isn't a rebuttal.  There's no requirement whatsoever
for the results of identity comparison to be related to the results of
value comparison, ergo they are disjoint.  Changing one doesn't have
to influence the other.  Please note that I never advocated doing what
Java does, I merely noted what it does.

> Python's idea is that, by default, any object is equal to itself and
> only itself.

Which is just wrong-headed.  Many types have no meaningful definition
for value equality, ergo any code that attempts to perform the
operation is incorrect.

> (*) nan == nan is false, but, at least conceptually, a 'NotComparable'
> exception should be raised instead. That wouldn't be very useful, though.

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


Which is the whole problem.  It's nice to keep erroneous conditions
out of your domain, but it's just not always possible.  I don't know
how you implement NaN (which you need) without allowing for this.  I
don't know how you implement SQL NULL without allowing for this.
While lots of problems can avoid this issue, I'm not sure all problems
can.  Moreover, I don't know how to implement a value comparison for
many objects, so the operation should just be undefined.

I should point out that I was a little hasty in painting Python with
the same brush as C# and excluding Java.  Python and Java are equally
bad: value equality defaults to identity equality but there are
distinct operations for telling them apart.  People want identity
equality in Python write 'is', not '=='.  People who explicitly want
value equality in Java write 'equals()'.  I apologize, and blame
skipping breakfast this morning.

C# is arguably worse, since '==' on objects is defined as identity
equality unless it has been overridden.  This means that that the
intent of the operation varies with no easy way to figure it out in
context, you simply have to know.  C# also provides a way to test only
for identity, Object.ReferenceEquals(), but it's underused.
Ultimately this is really a problem of documentation: the language
shouldn't encourage conflation of intent in the manner it does.

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

The only difference is I see is which comparison is performed by the
== symbol.  But I don't see how nor why Python's decisions are
superior to Java.  Plus, I never suggested that Python should do what
Java does, merely noted what it did since it seemed relevant to the
discussion.

Adam