[PATCH] context: explicitly return a tuple

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed May 28 13:16:27 CDT 2014



On 05/28/2014 10:48 AM, Sean Farley wrote:
> # HG changeset patch
> # User Sean Farley <sean.michael.farley at gmail.com>
> # Date 1401228288 18000
> #      Tue May 27 17:04:48 2014 -0500
> # Node ID ebae0401cb6b854420619962316005e814faad78
> # Parent  83bbfb23cb24b473286d528ddccbb333329f7f29
> context: explicitly return a tuple
>
> In the refactoring of removing localrepo.status, 2edb8648c500, we accidentally
> changed the return type from a tuple to a list. Philosophically, this is
> incorrect so we explicitly return a tuple again.
>
> diff --git a/mercurial/context.py b/mercurial/context.py
> --- a/mercurial/context.py
> +++ b/mercurial/context.py
> @@ -324,11 +324,13 @@ class basectx(object):
>                       self._repo.ui.status(_("skipping missing "
>                                              "subrepository: %s\n") % subpath)
>
>           for l in r:
>               l.sort()
> -        return r
> +
> +        # we return a tuple to signify that this list isn't changing
> +        return tuple(r)
>
>
>   def makememctx(repo, parents, text, user, date, branch, files, store,
>                  editor=None):
>       def getfilectx(repo, memctx, path):
> @@ -1444,11 +1446,11 @@ class workingctx(committablectx):
>           # 'memctx'?
>           s = super(workingctx, self).status(other, match, listignored, listclean,
>                                              listunknown, listsubrepos)
>           # calling 'super' subtly reveresed the contexts, so we flip the results
>           # (s[1] is 'added' and s[2] is 'removed')
> -        s[1], s[2] = s[2], s[1]
> +        s = s[2], s[1], s[3], s[4]

Isn't this going to have awful silent consequences when 5 < len(s) or 
when someone write code under alcohol influence and silently drop the 
[0] item?

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list