[issue37130] pathlib does not handle '..' directory
N.P. Khelili added the comment:
@Brett: Honestly I don't think it is the best way. But fact is:
nono@ACER ~ % cd /
nono@ACER / % python
Python 3.7.3 (default, Mar 26 2019, 21:43:19)
[GCC 8.2.1 20181127] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pathlib import Path
>>> Path('.') == Path('/')
False
In my humble and *very personal* opinion, this result could be understood in
the case of
a PurePath (or some kind of system call free) object. But that is not what
people expect
in the case of a 'normal' path...
I also think that one day we may see the rise of a new Os that wouldn't use .
and ..
The first Unix used 'd' for directory and 'dd' for directory's directory !
Those were hand-made links in a file system that otherwise had no concept of
hierarchy...
I think each flavour should have a special_dirs variable (fact that linux and
MsWin share
the same being an accident). And that the concept of a system-call free path
implementation,
is fragile.
--
___
Python tracker
<https://bugs.python.org/issue37130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37130] pathlib does not handle '..' directory
N.P. Khelili added the comment:
After digging the question,I'd rather go for a minimal change.
- setting .name to '' for '..'
- let it be known in the doc
- special-casing Path('..').stem (to keep the old behaviour)
- update tests
More could be done, but I don't feel like rewriting too much of it.
A global design change should set a special treatment for '..' as well as '.'
But I'd rather see small steps being accepted than big ones rejected.
--
___
Python tracker
<https://bugs.python.org/issue37130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37130] pathlib does not handle '..' directory
Change by N.P. Khelili : -- keywords: +patch pull_requests: +13887 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/14022 ___ Python tracker <https://bugs.python.org/issue37130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37130] pathlib does not handle '..' directory
N.P. Khelili 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 "", line 1, in
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
<https://bugs.python.org/issue37130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37199] Test suite fails when Ipv6 is unavailable
New submission from N.P. Khelili : The test suite does not handle an OS that does not have IPv6. When Linux kernel is started with argument: ipv6.disable=1 The test suite fails. ( See attached file ) 5 tests failed: test_asyncio test_imaplib test_importlib test_socket test_zipapp -- files: test_suite_fail.txt messages: 344970 nosy: Nophke priority: normal severity: normal status: open title: Test suite fails when Ipv6 is unavailable type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file48402/test_suite_fail.txt ___ Python tracker <https://bugs.python.org/issue37199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37130] pathlib.with_name() doesn't like unnamed files.
N.P. Khelili added the comment:
The idea in my last post was quite bad,
setting name to None breaks a lot of functions
that expect name to be a string.
Path('.').parent and Path('..').parent both return '.'.
Even if it is not stupid (regarding them as special dirs
pointing to somewhere else but still being inside the directory).
I don't know why anyone would rely on such a behaviour...
The tests expect Path('..').stem() to be '..'
and expect Path('.').stem() to be ''
Once again, I don't know why anyone should rely on it but
I fear I can't do a lot without breaking this one part of the test.
I'm working on it and posting something by the end of the Week.
--
___
Python tracker
<https://bugs.python.org/issue37130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37130] pathlib.with_name() doesn't like unnamed files.
N.P. Khelili added the comment: in the definition of the name property https://github.com/python/cpython/blob/9ab2fb1c68a75115da92d51b8c40b74f60f88561/Lib/pathlib.py#L792 : if len(parts) == (1 if (self._drv or self._root) else 0): return '' could also become if self.parent == self return '' # why not None btw... As I said, I'm new to python and I'll make a few tries once I build the test suite -- ___ Python tracker <https://bugs.python.org/issue37130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37130] pathlib.with_name() doesn't like unnamed files.
New submission from N.P. Khelili :
Hi guys!
I'm new to python and working on my first real project with it
I'm sorry if it's not the right place for posting this.
I noticed that that pathlib.with_name() method does not accept to give a name
to a path that does not already have one.
It seems a bit inconsistent knowing that the Path constructor does not require
one...
>>> Path()
PosixPath('.')
>>> Path().resolve()
PosixPath('/home/nono')
but:
>>> Path().with_name('dodo')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.7/pathlib.py", line 819, in with_name
raise ValueError("%r has an empty name" % (self,))
ValueError: PosixPath('.') has an empty name
whereas if you do:
>>> Path().resolve().with_name('dodo')
PosixPath('/home/dodo')
I first tought "explicit is better than implicit" and then why not allways use
resolve first! That was not a big deal but then I tried:
>>> Path('..').with_name('dudu').resolve()
PosixPath('/home/nono/dudu')
( ! )
>>> Path('..').resolve().with_name('dudu')
PosixPath('/dudu')
It seems that the dots and slashes are in fact not really interpreted leading
to:
>>> Path('../..').with_name('dudu')
PosixPath('../dudu')
>>> Path('../..').with_name('dudu').resolve()
PosixPath('/home/dudu')
( ! )
>>> Path('../..').resolve().with_name('dudu')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.7/pathlib.py", line 819, in with_name
raise ValueError("%r has an empty name" % (self,))
ValueError: PosixPath('/') has an empty name
Even if the doc briefly tells about this, I found this behavior quite
disturbing
I don't know what could be the correct answer to this,
maybe making Path('..') as invalid as Path('.'),
or adding a few more lines in the doc...
Sincerly yours,
--
components: Library (Lib)
messages: 344250
nosy: Nophke
priority: normal
severity: normal
status: open
title: pathlib.with_name() doesn't like unnamed files.
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
