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

Bernd Nawothnig Bernd.Nawothnig at t-online.de
Sat Apr 21 17:15:06 EDT 2012


On Sat, Apr 21, 2012 at 03:43:03PM -0400, Dave Angel wrote:
> 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.

Yes.
 
> 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
implementation detail.

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 ()





Bernd



More information about the Python-list mailing list