[merge] win32 cleanups
mbp at canonical.com
Wed Jun 14 10:22:19 BST 2006
On 11/06/2006, at 2:08 PM, John Arbash Meinel wrote:
> I took some time today to do some housekeeping with my win32
> branch. The
> attached patch shows what I've gotten to so far. It doesn't make all
> tests pass on win32, but it does make a whole bunch more pass than did
> 1) bzrlib.osutils._posix_abspath was using os.path.abspath rather than
> posixpath.abspath. I went ahead and cleaned up the code to copy
> posixpath.abspath only using os.getcwdu() instead of os.getcwd()
> 2) Windows has a completely separate api for unicode strings versus
> plain strings. As such, paths are not necessarily reachable by the
> plain-string apis. This is very different from Linux, where the
> plain-strings are bytestreams which happen to be utf8 encoded. So you
> can access all paths either way. (for example os.listdir('.') will
> return valid paths under Linux, on Win32 they will return '???' style
> This means that our handling of paths may be completely inverted
> Linux and Win32. Robert mentioned that it may be better to access
> as bytestreams, rather than assuming they can be cast into Unicode
> paths. And there are some good reasons for that (especially when
> the test suite with LANG=C).
On Unix it may be better to use bytestrings so that we have control
over how they're encoded, rather than relying on whatever Python
detects as filesystemencoding. The consensus seemed to be that using
the locale's encoding is generally the best bet, but it's only likely
to work well when the locale is utf-8.
But what effect will this have on Windows? Surely the only thing to
do there from what you just said is to pass Unicode?
> Anyway, I wanted to let people know these fixes were out there, and
> maybe get a review/+1. Even though not all tests are passing, more
> pass now, and it shouldn't break Linux stuff.
+0; it doesn't seem likely to break anything but I leave it up to you
and Alexander to decide if it should go in.
More information about the bazaar