[MERGE] bzrlib.osutils fixes

[Andrew Bennetts]

John Arbash Meinel wrote:
> Andrew Bennetts wrote:
[...]
> > 
> > I agree we should decide.  Personally, I think the constant would be better.
> > 
> > -Andrew.
> 
> As far as typos, that is what the test suite is for. :) I do realize
> that variables are a little more rigorous. You do have to start passing
> them around everywhere, though.

Test suites are a great tool for ensuring quality, but given the option I'd
rather have other tools to help as well :)

Part of my concern in this case is that a typo could potentially cause the right
answer most of the time (i.e. "foo is 'typo'" gives False), and it's often the
less-triggered code paths that aren't tested as rigourously as we might hope.

I do also worry that this is the first time we'd be knowingly relying on a
CPython optimisation as if it's a feature of the language.  I don't know if
PyPy, IronPython or Jython all copy this behaviour, but I suspect at least one
of them doesn't.
http://docs.python.org/lib/non-essential-built-in-funcs.html#l2h-90 simply says
"Normally, the names used in Python programs are automatically interned, and the
dictionaries used to hold module, class or instance attributes have interned
keys."  That's a far cry from "you can depend on x1 = 'foo'; x2 = 'foo'; x1 ==
x2".

> Is 'intern' part of the official python api, or is it a CPython
> implementation? It would seem part of python, since you have 'x is y'.

The intern builtin is part of the official API (although Guido regrets making
it a builtin rather than putting it somewhere like the sys module).
http://docs.python.org/lib/non-essential-built-in-funcs.html#l2h-90

As you can see there, the purpose of interning *isn't* that it allows "x is y"
comparisons for strings, it's to speed up dictionary lookups with strings (i.e.
str.__eq__).

Also, the "is" operator would exist whether or not there was an intern function
for strings; it's useful for lots of things that have nothing to do with
optimising string comparison.  It's even useful for many things that have
nothing to do with optimisations at all.

> I think it may look a lot better if we were just consistent, though. Having
> 
> {
> 'file':X,
> _directory_kind:Y,
> 'symlink':Z,
> }
> 
> Is pretty ugly, but having
> 
> kind_file:X,
> kind_directory:Y,
> kind_symlink:Z,
> 
> Isn't really any worse than the string counterpart.

Agreed.

-Andrew.