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

[Kiuhnm]

On 4/26/2012 20:54, Adam Skutt wrote:
> 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.

No, it can't be used between objects but only between primitives and 
references (which should be regarded as primitives, by the way). If you 
understand that your 'a' is not really an object but a reference to it, 
everything becomes clear and you see that '==' always do the same thing.
You might tell me that that's just an implementation detail, but when an 
implementation detail is easier to understand and makes more sense than 
the whole abstraction which is built upon it, something is seriously wrong.
The distinction between primitives and objects is unfortunate. It is as 
if Java tried to get rid of pointers but never completely succeeded in 
doing that.
It's the distinction between primitives and objects that should've been 
an implementation detail, IMO.

Python's lack of this misfeature is what I'm really fond of.

Everything else you said, I can agree on.

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

--
Kiuhnm