On Sat, Sep 25, 2010 at 7:11 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 26 Sep 2010 00:00:57 +1000 Ben Finney <ben+python@benfinney.id.au> wrote:
Antoine Pitrou <solipsis@pitrou.net> writes:
Again, why not simply improve realpath()?
Because that already does what it says it does.
So what? The behaviour of fetching the canonical name can be added to the behaviour of resolving symlinks. It wouldn't be incompatible with the current behaviour AFAICT. And it would be better than adding yet another function to our ménagerie of path-normalizing functions. We already have abspath(), normpath(), normcase(), realpath() -- all with very descriptive names as you might notice. We don't need another function.
There's no need to get all emotional or sarcastic about it. You might have noticed the risks of sarcasm on this list recently. Instead, it should be possibly to analyze how realpath() is currently used and see if changing it as desired is likely to break any code. TBH, I am personally on the fence and would like to see an analysis including the current and desired behavior in the following cases: - Windows - OS X - Other Unixoid systems Also take into account: - Filesystems whose case behavior is the opposite of the platform default (all three support such filesystems through system configuration and/or mounting) - Relative paths - Paths containing symlinks In any case it is much easier to design and implement the best possible functionality if you don't also have to be backward compatible with an existing function. I think it might be useful to call this new API (let's call it "casefulpath" while we wait for a better name to come to us :-) on a relative path without having the answer turned into an absolute path -- if that's desired it's easy enough to call abspath() or realpath() on the result. -- --Guido van Rossum (python.org/~guido)