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. 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). -- http://mail.python.org/mailman/listinfo/python-list
