Author Nophke
Recipients Jeffrey.Kintscher, Nophke, brett.cannon, terry.reedy
Date 2019-06-10.13:51:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
First, there is no real special case about the '.' path. The parse_args() method simlply removes then during __new__() (around line 80) as they are not needed. Double dots having to be kept, are later considered valid by the name @property.

In, '..' are just ignored in a lot of tests. In my previous post, I pointed the bahaviour of .stem and .parent. But we should also consider the question of .anchor. The doc says that it should return the """The concatenation of the drive and root, or ''."""

but the code is:

anchor = self._drv + self._root
return anchor

leading to:

>>> Path('.').anchor
>>> Path('..').anchor


>>> Path('foo').anchor

when one would probably expect '.', './..' and './foo'.

I also found:

>>> Path('*').match('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nono/BUILD/cpython/Lib/", line 956, in match
    raise ValueError("empty pattern")
ValueError: empty pattern

>>> Path('*').match('..')

While the behaviour of .stem (cf up msg 344770) dates from initial commit of test_pathlib, maybe breaking it may be a bad idea... ( I really don't know.)

I have a working code that sets name to '' for '..' and adds a special case in .stem() so that we do not remove any line in test_pathlib, but only adds some.

I think anyway, it is too soon for any pull request. Questions are:

- Should .name allways return a string, even if empty?
- Should P('..').parent really return '.'?
- Is it ok that .match() make that much difference between '.' and '..'?
- Am I correct in my expectations about .anchor ?
- May .stem behaviour be changed ?
Date User Action Args
2019-06-10 13:51:32Nophkesetrecipients: + Nophke, brett.cannon, terry.reedy, Jeffrey.Kintscher
2019-06-10 13:51:32Nophkesetmessageid: <>
2019-06-10 13:51:32Nophkelinkissue37130 messages
2019-06-10 13:51:31Nophkecreate