[MERGE] Repository.iter_files_bytes()

[Andrew Bennetts]

John Arbash Meinel wrote:
[...]
> Sorry I didn't look close enough. But this is what gettext does:
> 
> __builtin__.__dict__['_'] = unicode and self.ugettext or self.gettext

Nice.  Why stop at just one evil thing per line of code? ;)

[...]
> > So my confusion about what's wrong with using “_” still stands.
> > 
> > -Andrew.
> 
> Maybe it is just stuff like pdb and the python interpreter which do
> weird things with "_", but if you do:

Right, I can believe those cases.

[...]
> Now I *thought* that assigning to "_" was enough to trigger this. I
> can't seem to reproduce it.

Right, I didn't think you could reproduce it with that ;)

> So I'm *sure* that breaking into a debugger would cause bzr-gtk to
> crash, because it would try to internationalize() a string, and "_" had
> been overwritten. So at the very least, pdb and the general python
> interpreter write to the __builtin__.__dict__['_'] variable.
> 
> I *thought* that things were breaking anyway, which is why people were
> dropping into the debugger to try and fix it. But it is certainly
> possible that it was something else that was broken, and then the
> debugger broke their _ (or maybe they did so in some other part of the
> function without realizing it).

That seems most likely to me.  I believe the cause of _ being set by both
pdb and the interpreter prompt is that the default sys.displayhook does
that.  Probably in pdb's case sys.displayhook could/should be set to
something that doesn't modify builtins (it can always set "_" on a
pdb-specific namespace dict to preserve the end-user behaviour).  And for
that matter the Python interpreter itself could do the same thing with its
displayhook...

-Andrew.