N.P. Khelili <nop...@free.fr> added the comment:
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 test_pathlib.py, '..' 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
''
and:
>>> 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/pathlib.py", line 956, in match
raise ValueError("empty pattern")
ValueError: empty pattern
>>> Path('*').match('..')
False
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 ?
----------
title: pathlib.with_name() doesn't like unnamed files. -> pathlib does not
handle '..' directory
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue37130>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
