[issue37130] pathlib does not handle '..' directory

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm sorry, but I don't understand the issue here.

Instead of posting isolated snippets, could you explain what are you trying to 
do?

--

___
Python tracker 

___
___
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]

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 

___
___
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

[Brett Cannon]

Brett Cannon  added the comment:

@Antoine: was there a design reason behind setting 'name' to '' when a Path 
objects was initialized with '.'? Is it to implicitly represent the current 
directory?

@N.P.: we will have to think through the implications of this as I don't know 
if normalizing to 'name' being '' is the best way to resolve this inconsistency.

--
nosy: +pitrou

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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

[Brett Cannon]

Change by Brett Cannon :


--
assignee:  -> brett.cannon

___
Python tracker 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com