On Apr 25, 10:38 am, Nobody <nob...@nowhere.com> wrote:
> On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:
> >> 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.
>
> If anything is ill-defined, then it's "+" and "*", i.e. it's unspecified
> whether the value which they return is a unique object or a reference to
> some other object.
>
Such a definition precludes meaningful operator overloading and is
highly problematic for floating-point numbers. There's also no way to
enforce it, but I think you know that too. :)
Identity and equality are distinct concepts in programming languages.
There's nothing that can be done about that, and no particularly good
reason to force certain language behaviors because some "programmers"
have difficulty with the distinction.
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)
Though I would prefer:
addr(x) == addr(y)
myself, again, for what little it matters. The right thing to do when
confronted with this problem is teach the difference and move on.
As an aside, the whole problem with 'is' and literals is perhaps the
only really good argument for a 'new' keyword/operator like C++ and
Java have. Then it's more explicit to the programmer that they've
created two objects (in this case, anyway).
> More accurately, the existence of "is", "is not" and "id" cause many other
> constructs to have "ill-defined" behaviour.
>
> >> "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 what's wrong with that? If you want a language which precisely
> specifies all observable behaviour, you're going to end up with a rather
> useless language. For a start, it can't have a time() function. For
> similar reasons, you can't have networking or any form of preemptive
> concurrency (which includes any form of inter-process communication on an
> OS which uses preemptive multi-tasking).
Fully specified does not mean fully deterministic. What makes a
specification of "Any value in the range 0 through N" less 'full' than
a specification of "X" or a constant?
Adam
--
http://mail.python.org/mailman/listinfo/python-list
