On Sun, 22 Apr 2012 12:43:36 -0700, John Nagle wrote: > On 4/20/2012 9:34 PM, john.tant...@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 -- http://mail.python.org/mailman/listinfo/python-list
