This is correct:

relpath(r'd:\abc\jho', r'd:\abc')
=> 'jho'

But this isn't:
relpath(r'd:\jho', r'd:\\')
=> '..\jho'

Neither is this:
relpath(r'd:\jho', r'd:')
=> '..\..\..\jho'

About this,

>But this isn't:
>relpath(r'd:\jho', r'd:\\')
>=> '..\jho'

Same happens on posixpath.

from posixpath import relpath
print relpath(r'/abc', r'/') #=> ../abc

I'll look at the code.

The problem is with these lines:

    start_list = abspath(start).split(sep)
    path_list = abspath(path).split(sep)

In case of 'd:\', the split returns two elements, the second empty.

I hope attached patch will fix this bug.

It seems that there is still problem.

>>> ntpath.relpath("//whiterab-c2znlh/foo/", "//whiterab-c2znlh/bar/")
'..\\foo'

This should raise ValueError because "//whiterab-c2znlh/foo" is UNC root
prefix (like "e:" for normal path) not "//whiterab-c2znlh" AFAIK.

I'll look into more deeper...

I hope this works.

In case the behavior requested here is controversial, here's an example
of where it would be nice to have relpath(x, '/') return a path for x
that is relative to the root directory:

The 'oprofile' system profiler for Linux profiles everything running on
the system at once.  Its profile count database takes the form of a
directory tree of counter files that mirrors the whole filesystem:
/var/lib/oprofile/samples/current/{root}/bin/ls holds the samples for
/bin/ls, and so on.  Also, the 'opannotate' command annotates source
trees with profile counts: if /bin/ls were built from /src/ls.c, then
'opannotate -o ~/ann-tree' would put a count-annotated copy of ls's
source '~/ann-tree/src/ls.c'.

At the moment, I wish I could simply say:

src=path to source file
real_src = os.path.realpath(src)
rel_real_src = os.path.relpath(real_src, '/')
annotated_source = os.path.join(annotation_dir, rel_real_src)

but this bug gets in the way.

Maybe this patch should be updated because os.path functions changed
their behaviors for UNC in py3k. (#5799)

msg90061 refers to #5799 which is closed, fixed.  Will the attached patch need reworking as a result of the #5799 change?

In py3k, ntpath is almost fixed. but posixpath is not fixed yet.
ntpath has another problem about case sensitivity. I'll attach
the patch to fix ntpath's case issue and posixpath.

In Py27, ntpath has whole issue still there.

I'll create the patch for it.

Well, I said msg80877 past, and I think so too, but
os.path module of python2.x seems not to support UNC
correctly, and I'm not sure if the behavior change is
allowed here.

Probably UNC support is new feature, so I'll attach
the patch to solve only this problem as is.

Committed fixes in r85689(py3k), r85693(release31-maint),
r85694(release27-maint). (This should work because I 
simply ported already working fix in ntpath.relpath)

FYI, this fix broke some buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%202.7/builds/50 for instance. Gentoo too.

Broke bunches of 2.7 buildbots.  But why are we running test_ntpath on OS X, anyway?  Shouldn't this be skipped everywhere except win32 platforms?

No - the posixpath/ntpath routines are meant to be usable for path manipulation for posix/NT paths on any platform.

Then we need to revert this patch and find one that works.

Sorry, I've commit the fix in r85717(release27-maint).
I'll sit and watch buildbot.

I confirmed test runs fine on x86 Snow Leopard 2.7.
So I'm closing this issue....