[Python-ideas] reusing realpath()
Guido van Rossum
guido at python.org
Sat Sep 25 22:55:30 CEST 2010
On Sat, Sep 25, 2010 at 7:11 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 26 Sep 2010 00:00:57 +1000
> Ben Finney <ben+python at benfinney.id.au> wrote:
>> Antoine Pitrou <solipsis at pitrou.net>
>> > 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
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:
- 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)
More information about the Python-ideas