ntpath bug or expected?

dsavitsk dsavitsk at e-coli.net
Wed Sep 11 22:35:12 EDT 2002

<jepler at unpythonic.net> wrote in message
news:mailman.1031795954.4770.python-list at python.org...
> On Thu, Sep 12, 2002 at 01:18:21AM +0000, dsavitsk wrote:
> > python 2.1.3.  this is pretty minor ... os.path.join() on win32 fails if
> > first path component is C: (or any other letter).  that is, if the first
> > component is a drive letter, it must contain either '\\' or '/' or else
> > path is wrong.  this makes it the only component which must have
> >
> > example
> > >>> os.path.join('C:', 'path', 'to', 'file.txt')
> > C:path\\to\\file.txt
> Sure.  This is the file on drive C which is in the relative path
> "path\\to\\file.txt" from the current directory of drive C.

it seems to me, i guess, that being inconsistent here and in os.getcwd in a
consistent way is confusing.  if getcwd returned C: instead of C:\\ (as it
returnes C:\\path and not C:\\path\\) then
os.path.join(os.getcwd(), 'path', 'file.txt')
with my modification would do the same thing as it now does, but it would
have the added bonuses of returning a full file path and removing 2 bits of
necessary documentation from the language.

i'll go find something better to do now.


> Remember, DOS maintains a separate working directory for each drive.
> A first element of C:/ would make the path absolute, and a first element
> C: would make the path relative to the current directory of C.  I think
> that is why
>     >>> ntpath.join("C:", "/path", "to", "file.txt")
>     'C:/path\\to\\file.txt'
> is "correct".  This is the one I wonder about, though:
>     >>> ntpath.join("C:", "/a", "/b", "x.txt")
>     '/b\\x.txt'
>     >>> ntpath.join("C:/a", "/b", "x.txt")
>     '/b\\x.txt'
> if the drive letter is preserved in my first example, why isn't it in the
> last two?
> Jeff

More information about the Python-list mailing list