[PATCH 1 of 7] vfs: use propertycache for open

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Aug 11 15:24:58 EDT 2016



On 08/11/2016 08:25 PM, Augie Fackler wrote:
> On Fri, Aug 05, 2016 at 03:59:14PM +0200, Pierre-Yves David wrote:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
>> # Date 1470322610 -7200
>> #      Thu Aug 04 16:56:50 2016 +0200
>> # Node ID 9b65c0820c940442454e5f92a9475c4ec97f705c
>> # Parent  73ff159923c1f05899c27238409ca398342d9ae0
>> # EXP-Topic vfsward
>> vfs: use propertycache for open
>>
>> The current open method is currently behaving like a property cache. We use our
>> utility decorator to make this explicit.
>>
>> diff -r 73ff159923c1 -r 9b65c0820c94 mercurial/scmutil.py
>> --- a/mercurial/scmutil.py	Mon Aug 01 13:14:13 2016 -0400
>> +++ b/mercurial/scmutil.py	Thu Aug 04 16:56:50 2016 +0200
>> @@ -256,17 +256,15 @@ class abstractvfs(object):
>>                  raise
>>          return []
>>
>> -    def open(self, path, mode="r", text=False, atomictemp=False,
>> -             notindexed=False, backgroundclose=False):
>> +    @util.propertycache
>> +    def open(self):
>>          '''Open ``path`` file, which is relative to vfs root.
>>
>>          Newly created directories are marked as "not to be indexed by
>>          the content indexing service", if ``notindexed`` is specified
>>          for "write" mode access.
>>          '''
>> -        self.open = self.__call__
>> -        return self.__call__(path, mode, text, atomictemp, notindexed,
>> -                             backgroundclose=backgroundclose)
>> +        return self.__call__
>
> Is there a reason we can't just do `open = __call__` instead of the
> @property{,cache} trickery? What does using the property decorator
> mechanism really buy us here?

yes, pretty much all vfs subclass redefine __call__

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list