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

Dave Angel d at davea.name
Sat Apr 21 15:43:03 EDT 2012


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.

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?


-- 

DaveA



More information about the Python-list mailing list