[MERGE] Repository.iter_files_bytes()

[Andrew Bennetts]

Vincent Ladeuil wrote:
[...]
> Given that using '_' as an anonymous variable is a common idiom
> in python, this conflicts hard with gettext reserving '_' for its
> private usage by adding it to __global__ so that it can be
> accessed anywhere without importing gettext again.

I don't understand why that's such a big issue.  How many functions both use
'_' as an anonymous variable *and* want to use gettext?  The small minority
that do can use your workaround of importing gettext.gettext directly, or is
the problem that xgettext doesn't provide a way to cope with two possible
keywords?  Or does xgettext not cope with “_” sometimes not being used as a
gettext function?

I'd think it wouldn't be particularly hard to write a python-specific
gettext extractor that would find any foo("string") where foo is bound to
gettext.gettext (or '_' where it comes from the builtin name space) by doing
static analysis of the AST (like e.g. pyflakes does).

Also, any function that wants to use an anonymous variable and have a
translateable string can just choose a name for the anonymous variable that
doesn't conflict with a global/builtin that function wants to use, much as
you don't use “str” as a variable name if you want to use the builtin with
that name.  (Or "branch", to pick a more common example in bzrlib.)

I think the _i18n workaround is reasonable and easy, and I'm not proposing
anyone spends effort on a different solution.  I just don't understand why
people seem to claim that using that workaround is a hard requirement if any
function anywhere might use _ for its own purposes?

> But doing so is fragile as it means any *apparently* local use of
> '_' will in fact modify the globally gettext installed one.

Huh?  It sounds like you're saying that code like:

    # foo.py
    x = 1
    def func():
        x = 2
    func()
    print x == 1

would print False, which is clearly not the case in Python.  Assignment in a
function doesn't modify globals unless there is a “global” declaration in
that function, or unless I'm missing some very nasty magic.

I'm not particularly surprised that pdb is buggy, though, but that is
probably fairly easy to fix.

-Andrew.