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

[Steven D'Aprano]

On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:

> Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
>> I can't think of a single case where 'is' is ill-defined.
> 
> If I can't predict the output of
> 
>     print (20+30 is 30+20)  # check whether addition is commutative
>     print (20*30 is 30*20)  # check whether multiplication is
>     commutative
> 
> by just reading the language definition and the code, I'd have to say
> "is" is ill-defined.

The failure to predict the result of the above has nothing to do with 
"is". Your test doesn't test what you think it does, because the output 
doesn't just depend on the behaviour of "is". Aside from the properties 
of arithmetic, the result printed depends on at least six factors:

* the behaviour of "is" (known)
* the behaviour of the Python interpreter when evaluating arithmetic
  expressions (undefined)
* the behaviour of the interpreter when creating objects (undefined)
* the presence or absence of a keyhole optimizer (undefined)
* and how aggressive it is (undefined)
* any other optimizations the compiler might apply (undefined)

The *one* factor which actually is well-defined by the language and 
completely predictable is the thing that you are John are blaming for 
your failure to predict the outcome! That's simply surreal.

It isn't the "is" operator that is ill-defined. What actually is ill-
defined is the circumstances where a Python implementation uses the same 
object for equal results. And that is as it should be. The decision to 
recreate or reuse objects when needed should not be part of the language 
definition. Why do you care whether a, b = 1+2, 5-2 creates two objects 
or one? At most, that's a quality of implementation issue. It certainly 
doesn't affect the semantics of the language.


>> You're blaming 'is' for revealing what's really going on. 'is' is /not/
>> implementation-dependent. It's /what's going on/ that's
>> implementation-dependent.
>> "a is b" is true iff 'a' and 'b' are the same object. Why should 'is'
>> lie to the user?
> 
> Whether a and b are the same object is implementation-dependent.

And that has absolutely nothing to do with the behaviour of "is". The 
"is" operator is not responsible for whether a and b are the same object.

The "is" operator has an exact definition. There is nothing ill-defined 
about the "is" operator. That definition is simple enough for me to quote 
it in full:

    The operators is and is not test for object identity: x is y is
    true if and only if x and y are the same object. x is not y 
    yields the inverse truth value.

Taken from the last paragraph of here:
http://docs.python.org/py3k/reference/expressions.html#is


Short of having "is" be a null-op that always returns False, there are no 
changes you can make to the definition of "is" that will make "a is b" 
any more predictable.


-- 
Steven