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

Kiuhnm kiuhnm03.4t.yahoo.it
Thu Apr 26 08:17:28 EDT 2012


On 4/26/2012 2:01, Steven D'Aprano wrote:
> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>
>> Though, maybe it's better to use a different keyword than 'is' though,
>> due to the plain English
>> connotations of the term; I like 'sameobj' personally, for whatever
>> little it matters.  Really, I think taking away the 'is' operator
>> altogether is better, so the only way to test identity is:
>>      id(x) == id(y)
>
> Four reasons why that's a bad idea:
>
> 1) The "is" operator is fast, because it can be implemented directly by
> the interpreter as a simple pointer comparison (or equivalent). The id()
> idiom is slow, because it involves two global lookups and an equality
> comparison. Inside a tight loop, that can make a big difference in speed.
>
> 2) The "is" operator always has the exact same semantics and cannot be
> overridden. The id() function can be monkey-patched.
>
> 3) The "is" idiom semantics is direct: "a is b" directly tests the thing
> you want to test, namely whether a is b. The id() idiom is indirect:
> "id(a) == id(b)" only indirectly tests whether a is b.
>
> 4) The id() idiom already breaks if you replace names a, b with
> expressions:
>
>>>> id([1,2]) == id([3,4])
> True

You forgot one:
5) It would be a pain to write (and read)
      if id(my_obj) == id(None)
    and so anyone would come up with his/her own same_as(), 
identical_to(), same_inst() and so on...

Kiuhnm



More information about the Python-list mailing list