andrew.bennetts at canonical.com
Fri Mar 27 00:41:27 GMT 2009
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
More information about the bazaar