why () is () and [] is [] work in other way?
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Mon Apr 23 00:34:34 EDT 2012
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
More information about the Python-list
mailing list