[PATCH 4 of 8] opener: add read & write utility methods

Dan Villiom Podlaski Christiansen danchr at gmail.com
Sat Dec 25 05:29:27 CST 2010


On 25 Dec 2010, at 01:48, Adrian Buehlmann wrote:

> On 2010-12-25 01:35, Dan Villiom Podlaski Christiansen wrote:
>
>> @@ -221,6 +223,8 @@ class encodedstore(basicstore):
>>         op = opener(self.path)
>>         op.createmode = self.createmode
>>         self.opener = lambda f, *args, **kw: op(encodefilename(f),  
>> *args, **kw)
>> +        self.opener.read = (lambda f, *args, **kw:
>> +                            op(encodefilename(f), *args, **kw).read 
>> ())
>
> I hope this is not pushed, like I already said.
>
> Dan and I disagree here but he insists on this.

So I insist, eh? You didn't respond to my mail where I explained why I  
did it, and later posted a mail describing how you'd like it done. So  
I just assumed that we agreed to disagree.

This is all the reasoning you've provided:

> IMHO, this is too intrusive. You shouldn't have to add a read member  
> function to
> every opener.

Please elaborate. Why is it too intrusive? What's wrong with adding a  
read member to every opener? (Where “every” means the opener class and  
the three places that provide a custom opener.)

--

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/20101225/895224c3/attachment.bin>


More information about the Mercurial-devel mailing list