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

[Adam Skutt]

On Apr 26, 2:31 pm, John Nagle <na... at animats.com> wrote:
> On 4/26/2012 4:45 AM, Adam Skutt wrote:
> > On Apr 26, 1:48 am, John Nagle<na... at animats.com>  wrote:
> >> On 4/25/2012 5:01 PM, 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).
>
> >>      This assumes that everything is, internally, an object.  In CPython,
> >> that's the case, because Python is a naive interpreter and everything,
> >> including numbers, is "boxed".  That's not true of PyPy or Shed Skin.
> >> So does "is" have to force the creation of a temporary boxed object?
>
> > That's what C# does AFAIK.  Java defines '==' as value comparison for
> > primitives and '==' as identity comparison for objects, but I don't
> > exactly know how one would do that in Python.
>
>     I would suggest that "is" raise ValueError for the ambiguous cases.
> If both operands are immutable, "is" should raise ValueError.

I don't know how you would easily detect user-defined immutable types,
nor do I see why such an operation should be an error.  I think it
would end up violating the principal of least surprise in a lot of
cases, especially when talking about things like immutable sets, maps,
or other complicated data structures.

What I think you want is what I said above: ValueError raised when
either operand is a /temporary/ object.  Really, it should probably be
a parse-time error, since you could (and should) make the
determination at parse time.

> That's the case where the internal representation of immutables
> shows through.

You still have this problem with mutable temporary objects, as my
little snipped showed. You're still going to get a result that's
inconsistent and/or "surprising" sooner or later.  The problem is the
temporary nature of the object, not mutability.

>
>     If this breaks a program, it was broken anyway.  It will
> catch bad comparisons like
>
>      if x is 1000 :
>         ...
>
> which is implementation dependent.

Yes, I agree that a correct fix shouldn't break anything except
already broken programs.

Adam