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.

Author babou
Recipients babou, r.david.murray
Date 2013-03-26.20:15:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1364328959.56.0.0286006796538.issue17545@psf.upfronthosting.co.za>
In-reply-to
Content
Reply to R.David.Murray

> See also issue 6095.

You are right. I goofed, this is the issue I meant to point to.

> $ ls ''
> ls: cannot access : No such file or directory
> So, the behavior is consistent with the shell.

This is a fair remark.
But still, giving a meaning to something that has none in the shell would not be an inconsistency either. There are lots of other differences in the Unix shell design, and strings are often used as a syntactic device. You do not have to quote file names or paths, unless they raise syntactic problems.

Now if you look at path manipulation commands in the shell, you have :

$ basename aaa
aaa
$ dirname aaa
.

This is a fair choice for the shell since an empty path would print as nothing. Furthermore, string manipulation is not as convenient with the shell as it is with Python. So the shell is altogether ignoring the empty path, and string manipulations (possibly using the empty string) to build a path representation are not part of the path system.

Python has already made a different choice.

In [4]: os.path.basename('aaa')
Out[4]: 'aaa'

In [5]: os.path.dirname('aaa')
Out[5]: ''

These are the two results of os.path.split('aaa'), which is somewhat the inverse of os.path.join(...) which I initially considered.

So os.path.dirname in Python does return the empty string '' where the shell dirname returns a dot. This could also be seen as an inconsistency between Unix shell and Python.

However, the Unix shell is internally consistent, while taking into account its own specific constraints.

It seems that it is more important for Python to similarly have its own internal consistency, especially when considering that Python is already departing from Unix shell in some minor ways, which are related to the internal consistency issue that was raised.
History
Date User Action Args
2013-03-26 20:15:59babousetrecipients: + babou, r.david.murray
2013-03-26 20:15:59babousetmessageid: <1364328959.56.0.0286006796538.issue17545@psf.upfronthosting.co.za>
2013-03-26 20:15:59baboulinkissue17545 messages
2013-03-26 20:15:59baboucreate