Bernd.Nawothnig at t-online
Apr 21, 2012, 2:15 PM
Post #20 of 142
On Sat, Apr 21, 2012 at 03:43:03PM -0400, Dave Angel wrote:
Re: why () is () and  is  work in other way?
[In reply to]
> On 04/21/2012 09:48 AM, Bernd Nawothnig wrote:
> > On Sat, Apr 21, 2012 at 09:21:50AM -0400, Dave Angel wrote:
> >>>>>>>  is 
> >>>> False
> >>> Same for that.
> >> Here I have to disagree. If an implementation reused the list object
> >> for two simultaneously-existing instances, it would violate first
> >> principles.
> > Hm.
> > Even if there is no chance to reach any of these two lists after the
> > comparison because *no* references to them exist and both *must* be
> > identical because they are both noted as the same literals?
> > If any references exist, no question, that is pretty clear and
> > understandable. But in that special case?
> You forgot to CC the list on your two messages to me.
Sorry, I'm reading the list via usenet gateway. Hopefully it works now.
> Clearly, False has to be a valid return result. So I assume your
> question is why shouldn't an implementation be permitted to return True,
> in other words why couldn't it be ambiguous, like the immutable case.
> Why would you (a hypothetical compiler writer) write an optimizer to
> look for such a special case like this, when the code would probably
> never appear in a real program, and certainly not in a performance
> critical portion of one.
> And if you did write one, why would you have it produce a different
> result than the non-optimized version? Why not have it return 42 if
> that's the goal?
My original statement was: don't rely on such behaviour, it is an
Your argument above was: it would violate first principles. And I still don't
see that point. The comparison  is  maybe totally useless, of course, but
which first principle would be violated by a compiler that lets that
expression evaluate to True?
Where can I read that the result *must* be False?
Otherwise it is simply an ambigious and not clearly defined expression like
() is ()