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

[John Nagle]

On 4/22/2012 3:17 PM, John Roth wrote:
> On Sunday, April 22, 2012 1:43:36 PM UTC-6, John Nagle wrote:
>> On 4/20/2012 9:34 PM, john.tantalo at gmail.com wrote:
>>> On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:
>>>
>>>> I believe it says somewhere in the Python docs that it's
>>>> undefined and implementation-dependent whether two identical
>>>> expressions have the same identity when the result of each is
>>>> immutable
>>
>> Bad design.  Where "is" is ill-defined, it should raise
>> ValueError.
>>
>> A worse example, one which is very implementation-dependent:
>>
>> http://stackoverflow.com/questions/306313/python-is-operator-behaves-unexpectedly-with-integers
>>
>>
>>
>>> a = 256
>>>>> b = 256 a is b
>> True           # this is an expected result
>>>>> a = 257 b = 257 a is b
>> False
>>
>> Operator "is" should be be an error between immutables unless one
>> is a built-in constant.  ("True" and "False" should be made hard
>> constants, like "None". You can't assign to None, but you can
>> assign to True, usually with unwanted results.  It's not clear why
>> True and False weren't locked down when None was.)
>>
>> John Nagle
>
> Three points. First, since there's no obvious way of telling whether
> an arbitrary user-created object is immutable, trying to make "is"
> fail in that case would be a major change to the language.

    If a program fails because such a comparison becomes invalid, it
was broken anyway.

    The idea was borrowed from LISP, which has both "eq" (pointer 
equality) and and "equals" (compared equality).  It made somewhat
more sense in the early days of LISP, when the underlying
representation of everything was well defined.

> Second: the definition of "is" states that it determines whether two
> objects are the same object; this has nothing to do with mutability
> or immutability.
>
> The id([]) == id([]) thing is a place where cPython's implementation
> is showing through. It won't work that way in any implementation that
> uses garbage collection and object compaction. I think Jython does it
> that way, I'm not sure about either IronPython or PyPy.

    That represents a flaw in the language design - the unexpected
exposure of an implementation dependency.

> Third: True and False are reserved names and cannot be assigned to in
> the 3.x series. They weren't locked down in the 2.x series when they
> were introduced because of backward compatibility.

     That's one of the standard language designer fuckups.  Somebody
starts out thinking that 0 and 1 don't have to be distinguished from
False and True.  When they discover that they do, the backwards
compatibility sucks.  C still suffers from this.

					John Nagle