[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