[PATCH 2 of 8] cmdalias & wrapcommand: remove is-comparisons with non-singletons

Thu Nov 18 10:15:26 CST 2010

On 16 Nov 2010, at 23:54, Martin Geisler wrote:

> Dan Villiom Podlaski Christiansen <danchr at gmail.com> writes:
>
>> # HG changeset patch
>> # User Dan Villiom Podlaski Christiansen <danchr at gmail.com>
>> # Date 1289939758 -3600
>> # Branch stable
>> # Node ID b5093e797e19679cc8e7b01a7fd41feba94c6c27
>> # Parent  26ddc30bd301eadc5278e2161ebdae91a1a28025
>> cmdalias & wrapcommand: remove is-comparisons with non-singletons.
>>
>> Regular equality comparisons are used instead. In the case of command
>> table entries, this will compare the values rather than object
>> identity. This should be safe, if ever so slightly slower.
>
> I don't think it's a matter of being safe -- it's a matter of  
> comparing
> objects and there the 'is' operator is just fine. It is only when
> comparing an object with a literal that we can get into trouble.
>
> The code below is not interested in knowing if the entry returned by
> cmdutil.findcmd is an unrelated object that is equal in value to e, it
> wants to know if entry 'is' e. So I would not change this.

(I just picked this mail to respond to, but think of it as a response  
to both all the replies.)

To be clear, I don't really have a strong opinion on this. If you guys  
prefer using ‘is’, that's fine with me. Although I have a reasonably  
good understanding of the Python syntax, I'll happily admit to not  
being familiar with what's considered pythonic.

That being said, my understanding of the semantics of ‘==’ seems to be  
different from yours. I'd describe the Python semantics for equality as:
- structural equality, where that makes sense
- object identity otherwise

In other words, two objects ‘a’ and ‘b’ would only compare equal if an  
operation on ‘a’ would have the same results as doing the same  
operation on ‘b’. There are exceptions to this, of course, and the  
main instance of this I can think of is mutable types: while doing  
‘x.append(42)’ will have the same results when done on anything that  
compares equal to ‘x’, the side-effects of the operation are likely to  
be of interest.

In most of the cases you or Mads objected to, the notion of equality  
used by the types in that instance was object identity. For example, a  
file descriptor shouldn't compare equal to anything but itself, nor  
will a UI instance, nor will a simple object().

I mainly wrote these patches so we could see if not using ‘is’ would  
work, and how such a change would look. In most cases, the only  
difference would be in presence of a horribly nasty object that  
claimed to be equal everything. This patch was the one I was most in  
doubt, though, and (AFAICT) the only one where the new comparison  
could fail on valid input. (I believe it would fail in the case of two  
equal command definitions where only the function differed. Such use  
would be odd, but valid.) This code seemed a bit weird to me, so I  
wrote a patch today to change the used function to also return the  
command table key. I'll probably send it to the list tomorrow.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20101118/ac089372/attachment.bin>