[MERGE] fix blackbox failures when run from windows executable

[Andrew Bennetts]

Mark Hammond wrote:
[...]
> > Transport.local_abspath is supposed to be the absolute path on the
> > local filesystem.  I'm a little surprised that local_abspath is 
> > different to the realpath.  Is it just a \ vs. / issue?
> 
> Exactly - / vs \.  Maybe a path.replace("/", os.path.sep) would be better?

I think I'd mildly prefer that.  That at least makes it clear that there's no
fundamental change to the path being represented, just a cosmetic change of
representation.

> > In fact, the docstring for Transport.local_abspath says:
> > 
> >         This function is quite expensive: it calls realpath which
> > resolves symlinks.
> > 
> > So I think perhaps the right fix might be to fix
> > Transport.local_abspath (i.e.
> > urlutils._win32_local_path_from_url) rather than these tests?
> 
> I'm inclined to agree with you about that - the function name implies native
> seps should be used - however I brought this up with Robert on IRC and he
> argued that this was still an 'internal path string', and as it would work
> with all os functions, it was not a problem, and steered me towards that test
> fix.
> 
> My opinion is that if this function intends to serve as an api for getting a
> "native" path that applications may call, it should use native seps - but if
> it is indeed considered internal, I see no problem with it staying as it is.

Hmm, I think Robert's right that that's for internal use.  So in that case the
only change to Transport.local_abspath we should make is clarifying the
docstring, because at the moment it implies that it will produce the something
equivalent to os.path.realpath's output.

-Andrew.