This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: os.path.dirname() does not behave as expected for path without /:es
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Jonas.Eriksson, r.david.murray
Priority: normal Keywords:

Created on 2013-07-24 16:31 by Jonas.Eriksson, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (2)
msg193662 - (view) Author: Jonas Eriksson (Jonas.Eriksson) Date: 2013-07-24 16:31
Only tested on marked python versions. Checked the code in hg (a5681f50bae2) and did not see anything related to this in the current development version.

Essentially, what I see is this:
>>> os.path.dirname("asdf")
''
>>> os.path.dirname("./asdf")
'.'
>>> 

What I expect is the same output as from the unix command dirname:
$ dirname asdf
.
$ dirname ./asdf
.
$ 

The change is quite straight forwards, Lib/posixpath.py needs something like if head = "": head = ".", and Lib/ntpath.py something similar.

Now, this bug is a tricky one since it alters the behavior of dirname. However, I cannot see any case where "" would be useful and have seen at least one bug because of this behaviour because the return value "" is treated like an error. So I gracefully hand over the final decision to you :)
msg193668 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-07-24 19:17
Oh, it would definitely be a backward compatibility issue.  Imagine code that does a dirname and branches like this:

   d = dirname(somepath)
   if d:
       <handle directory>
    else:
       <no directory case>

Or to give a more concrete example:

   path = fn if dirname(fn) else os.path.join(defaultdir, fn)

As you can see, the current behavior has significant value in Python.  So I think it is behaving correctly.  Python is not the shell, even though it does have many functions that provide APIs very similar to the corresponding shell functions.

See issue 17545 for a related issue, and specifically msg189401 for another reason why the current behavior of dirname is correct within the logic of Python.

Based on the above I'm going to go ahead and close this.  If other developers disagree they can reopen.  If they don't, and you disagree, I would suggest that talking about it on python-ideas would be your next step.
History
Date User Action Args
2022-04-11 14:57:48adminsetgithub: 62747
2013-07-24 19:17:05r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg193668

resolution: rejected
stage: resolved
2013-07-24 16:31:59Jonas.Erikssoncreate