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

[Steven D'Aprano]

On Sun, 22 Apr 2012 12:43:36 -0700, 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.

"is" is never ill-defined. "is" always, without exception, returns True 
if the two operands are the same object, and False if they are not. This 
is literally the simplest operator in Python.

John, you've been using Python for long enough that you should know this. 
I can only guess that you are trolling, although I can't imagine why.


> 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

Why do you expect that? What part of the language semantics makes you 
think that the two statements:

a = 256
b = 256

must use the one object instead of creating two distinct objects?


>  >>> a = 257
>  >>> b = 257
>  >>> a is b
> False
> 
> Operator "is" should be be an error between immutables unless one is a
> built-in constant.

I cannot imagine any rationale for that insane design choice.

For starters, it makes it impossible to use custom sentinels when you 
need to distinguish between None as a valid argument and "argument 
missing". E.g.:

_SENTINEL = object()

def func(x, y=_SENTINEL):
    if y is _SENTINEL:
        y = something_else()
    process(x, y)


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

True and False were made keywords over three years ago, in Python 3.0.

http://docs.python.org/dev/whatsnew/3.0.html#changed-syntax


> It's not clear why True and False weren't locked down when None was.)

It's pretty clear to me.

Assignment to None has never been a common thing to do, hence the amount 
of code broken by making None a keyword in Python 2.4 was insignificant.

On the other hand, assignment to True and False was *very* common for 
code written prior to version 2.3, hence making True and False keywords 
before version 3 would have broken a lot of otherwise working code for 
little or no benefit.



-- 
Steven