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