> From: Guido van Rossum
>
> > I'm not sure whether to classify this as a bug or a feature request.
> > Recently, I got burned by the fact that despite the name, dirname()
> > does not return the expected directory portion of a path if you pass
> > it a directory, instead it will return the parent directory because
> > it uses split.
>
> This is the first time I've ever heard of this confusion. dirname is
> named after the Unix shell function of the same name, which behaves
> the same way.
Well that's news. I never heard of or used dirname in the shell. But with
that historical context it makes more sense now.
> I'm not even sure I understand what you expected -- you expected
> dirname("foo") to return "foo" if foo is a directory? What would be
> the point of that?
Yes, I expected to get the directory passed in based on the function name.
In the code in question I don't know whether the path is a directory or a
file when I call dirname. I was simply misled by the function name. Looking
at this further I can see that I'm just going to have to create my own
directory(path) function because of how os.path.split behaves which impacts
dirname, I definitely need an isdir() check.
>>> os.path.split('c:\\mypython\\bugs\\')
('c:\\mypython\\bugs', '')
>>> os.path.split('c:\\mypython\\bugs')
('c:\\mypython', 'bugs')
Hmm, I may actually switch to using split(path)[0] and split(path)[-1] (or
split(path)[1]) in some cases since those might be more descriptive of what
dirname and basename actually do. Pity the functions aren't named
os.path.head and os.path.tail.
Sorry for the confusion,
ka
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4