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

Benjamin Kaplan benjamin.kaplan at case.edu
Mon Apr 23 13:21:44 EDT 2012


On Mon, Apr 23, 2012 at 1:01 PM, Paul Rubin <no.email at nospam.invalid> wrote:
>
> Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
> > I can't think of a single case where 'is' is ill-defined.
>
> If I can't predict the output of
>
>    print (20+30 is 30+20)  # check whether addition is commutative
>    print (20*30 is 30*20)  # check whether multiplication is commutative
>
> by just reading the language definition and the code, I'd have to say
> "is" is ill-defined.
>

The "is" operator is perfectly defined. But it doesn't check to see
whether two objects hold equivalent values, it checks whether they are
the same thing. You're not interested in whether 20+30 and 30+20 are
the same object, you're interested in whether they return equivalent
values which should be checked with ==.

> > You're blaming 'is' for revealing what's really going on. 'is' is
> > /not/ implementation-dependent. It's /what's going on/ that's
> > implementation-dependent.
> > "a is b" is true iff 'a' and 'b' are the same object. Why should 'is'
> > lie to the user?
>
> Whether a and b are the same object is implementation-dependent.
> --

And if I try running "from java.util import ArrayList" in CPython it
will give me an import error. It doesn't mean that the import
mechanism is broken because it returns different results in different
implementations of Python.



More information about the Python-list mailing list