PyWart: os.path needs immediate attention!

[Chris Angelico]

On Sat, Jul 30, 2011 at 6:44 AM, Corey Richardson <kb1pkl at aim.com> wrote:
> Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011:
>>  * New path module will ONLY support one path sep!
>
> People who use windows are used to \ being their pathsep. If you show
> them a path that looks like C:/whatever/the/path in an app, they are
> going to think you are nuts. It isn't up to us to decide what anyone
> uses as a path separator. They use \ natively, so should we. If at
> any point Windows as an OS starts using /'s, and not support, actually
> uses (in Windows Explorer as default (or whatever the filebrowser's
> name is)), it would be great to switch over.

Just tested this: You can type c:/foldername into the box at the top
of a folder in Explorer, and it works. It will translate it to
c:\foldername though.

We are not here to talk solely to OSes. We are here primarily to talk
to users. If you want to display a path to the user, it's best to do
so in the way they're accustomed to - so on Windows, display
backslashes.

>>  - normcase --> path = path.lower()
>
> Not quite, here are a few implementations of normcase (pulled from 2.7)
>
> # NT
>    return s.replace("/", "\\").lower()
>
> # Mac (Correct in this case)
>    return path.lower()
>
> # POSIX
>    return s
>
> But I can't think of where I would ever use that. Isn't case important on
> Windows?

No, as is demonstrated by the three above; case isn't important on
Windows, but it is on Unix.

>>  - normpath --> should not need this!
>
> Why not? It provides an OS-independent way to make the pathname look pretty,
> maybe for output? I don't really see a use for it, to be honest.

See above, we talk to users.

> But I'd
> rather there be a working solution in the stdlib than have everyone need to
> throw in their own that might not handle some things properly.

Absolutely!
>>  * basename --> should be: filename
>
> I agree. The name is a carryover from basename(1) and I guess it's good for
> those people, but it certainly isn't the least surprising name. If anything,
> I would think the base is everything before!

Agreed that it's an odd name; to me, "basename" means no path and no
extension - the base name from r"c:\foo\bar\quux.txt" is "quux".
Unfortunately that's not what this function returns, which would be
"quux.txt".

ChrisA