Attached is a patch for sf bug #796219 that fixes
ntpath.expanduser() for paths that embed other
environment variables, and also includes functionality
that mirrors *nix-style ~user\extra expansions.

I will comment with output from both the unpatched and
patched version of ntpath.

Logged In: YES 
user_id=341410

#test setup:
>>> import os
>>> os.environ['TESTING'] = '%TESTING1%'
>>> os.environ['TESTING1'] = '%TESTING2%'
>>> os.environ['TESTING2'] = 'Final\\Path'

#test standard ntpath
>>> import ntpath
>>> ntpath.expanduser('~')
'C:\\Documents and Settings\\jcarlson'
>>> ntpath.expanduser('~billy')
'~billy'
>>> ntpath.expanduser('~billy\\bob')
'~billy\\bob'
>>> ntpath.expanduser('~\\bob')
'C:\\Documents and Settings\\jcarlson\\bob'
>>>
ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%')
'~billy\\%TESTING%\\%TESTING1%\\%TESTING2%'

#test patched ntpath
>>> import ntpath_patched
>>> ntpath_patched.expanduser('~')
'C:Documents and Settings\\jcarlson'
>>> ntpath_patched.expanduser('~billy')
'C:Documents and Settings\\billy'
>>> ntpath_patched.expanduser('~billy\\bob')
'C:Documents and Settings\\billy\\bob'
>>> ntpath_patched.expanduser('~\\bob')
'C:Documents and Settings\\jcarlson\\bob'
>>>
ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%')
'C:Documents and
Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path'

Logged In: YES 
user_id=341410

I uploaded the testing as text to alleviate text wrapping
issues that could confuse.

Logged In: YES 
user_id=943591

this problem maybe is whats
needed

Logged In: YES 
user_id=341410

What problem is needed?

Perhaps you mean "this solution is desireable".

Logged In: YES 
user_id=6656

This looks much better to me!

Logged In: YES 
user_id=6656

bugger, wrong report :-/

Logged In: YES 
user_id=341410

I've just attached an updated version of the patch to handle
expandusers (without recursive environment variable
expansion), as well as a variant of
http://python.org/sf/1574252 to handle %VAR% style
expansions on Windows.

The patch looks good to me; documentation updates and new tests will be needed though.

This fixes #796219.

I have just attached an updated patch (against trunk) for ntpath expandusers and expandvars that includes documentation and test updates.
File Added: ntpath_full.patch

Thanks! Committed as rev. 54364.

I just saw this bug entry in the whatsnew list. The os.path.expanduser()
function handles ~user the wrong way. The (naive) implementation expects
that all user directories are inside a common base path. This is only
true for standalone Windows computers.

There is no way to get the path to a user's home directory w/o her
login+password or the login of a domain admin. The feature should be
removed in 2.6.1.

Martin, do you concur?

> Martin, do you concur?

Not really. On my system, which is part of a domain, expanduser("~")
gives 'C:\\Documents and Settings\\martin.vonloewis', which is
indeed the directory where my profile lives. HOMEDRIVE is Y:,
and HOMESHARE is some system in our network, but those aren't
considered for determining ~ - although I do think
%HOMEDRIVE%\%HOMEPATH% might have been a better choice.
However, given the choice that was made, I think the assumption
is correct that somebody else's profile will live in the same
folder. Is it possible to configure a domain profile so that it's
not in Documents and Settings?

Even if this doesn't work for all systems, I don't think we can
revert it for 2.6.1 (as it does give the correct answer at least
in some cases). Such a change will have to wait for 2.7.

Just ran into this myself, and would agree with Christian's comments. On
my system, my home directory is a mounted network drive, hence "H:\". It
was a bit of a surprise when os.path.expanduser("~fred") returned
"H:\\fred"...

This seems broken to me. It's surely better to have reliable functions
that either work or return the path unchanged, than ones that guess and
are wrong some of the time. At least in the above case it should be
possible to add a special case.

Will this be considered for Python 2.7 now? I'd suggest opening a new
bug or reopening this one if so.

In fact, wouldn't a very simple fix be to not return paths that don't
exist? That would probably catch 90% of the cases.