The desired behaviour for resolve() when the path doesn't exist
Dear friends, This is related with ticket 19717: "resolve() fails when the path doesn't exist". Assuming /home/cutecat exists but not /home/cutecat/aa, what is the desired output of Path('/home/cutecat/aa/bb/cc').resolve(strict=False)? Should it be: "/home/cutecat" (the existed path only), "/home/cutecat/aa" (the first non-existed path; my current strategy), or "/home/cutecat/aa/bb/cc" (the default behaviour of os.path.realpath)? Vajrasky
06.01.14 12:38, Vajrasky Kok написав(ла):
This is related with ticket 19717: "resolve() fails when the path doesn't exist".
Assuming /home/cutecat exists but not /home/cutecat/aa,
what is the desired output of Path('/home/cutecat/aa/bb/cc').resolve(strict=False)?
Should it be:
"/home/cutecat" (the existed path only), "/home/cutecat/aa" (the first non-existed path; my current strategy), or "/home/cutecat/aa/bb/cc" (the default behaviour of os.path.realpath)?
The readlink command has three canonicalize modes `-f' `--canonicalize' Activate canonicalize mode. If any component of the file name except the last one is missing or unavailable, `readlink' produces no output and exits with a nonzero exit code. A trailing slash is ignored. `-e' `--canonicalize-existing' Activate canonicalize mode. If any component is missing or unavailable, `readlink' produces no output and exits with a nonzero exit code. A trailing slash requires that the name resolve to a directory. `-m' `--canonicalize-missing' Activate canonicalize mode. If any component is missing or unavailable, `readlink' treats it as a directory. Behavior of os.path.realpath() is equivalent to --canonicalize-missing. Current behavior of pathlib.Path.resolve() is equivalent to --canonicalize-existing. Behavior of --canonicalize-existing can be derived from --canonicalize, just check that resulting patch exists. But other modes can't be derived from --canonicalize-existing. def resolve_existing(path): path = path.resolve() if not path.exists(): raise FileNotFoundError(errno.ENOENT, 'No such file or directory: %r' % str(path)) return path So perhaps two main modes should be --canonicalize (default) and --canonicalize-missing (with missing=True)?
On Tue, 07 Jan 2014 17:26:20 +0200 Serhiy Storchaka <storchaka@gmail.com> wrote:
Behavior of --canonicalize-existing can be derived from --canonicalize, just check that resulting patch exists. But other modes can't be derived from --canonicalize-existing.
def resolve_existing(path): path = path.resolve() if not path.exists(): raise FileNotFoundError(errno.ENOENT, 'No such file or directory: %r' % str(path)) return path
So perhaps two main modes should be --canonicalize (default) and --canonicalize-missing (with missing=True)?
That sounds reasonable. And I think strict should be the default. Regards Antoine.
07.01.14 22:28, Antoine Pitrou написав(ла):
So perhaps two main modes should be --canonicalize (default) and --canonicalize-missing (with missing=True)?
That sounds reasonable. And I think strict should be the default.
--canonicalize is not strict. --canonicalize-existing is most strict and --canonicalize-missing is least strict. When you have a function which have non-strict behavior (--canonicalize), you can implement a wrapper with strict behavior (--canonicalize-existing), but not vice verse.
On Tue, 07 Jan 2014 22:45:54 +0200 Serhiy Storchaka <storchaka@gmail.com> wrote:
07.01.14 22:28, Antoine Pitrou написав(ла):
So perhaps two main modes should be --canonicalize (default) and --canonicalize-missing (with missing=True)?
That sounds reasonable. And I think strict should be the default.
--canonicalize is not strict. --canonicalize-existing is most strict and --canonicalize-missing is least strict. When you have a function which have non-strict behavior (--canonicalize), you can implement a wrapper with strict behavior (--canonicalize-existing), but not vice verse.
Yes, I meant --canonicalize should be the default. Regards Antoine.
On Wed, Jan 8, 2014 at 4:45 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
--canonicalize is not strict. --canonicalize-existing is most strict and --canonicalize-missing is least strict. When you have a function which have non-strict behavior (--canonicalize), you can implement a wrapper with strict behavior (--canonicalize-existing), but not vice verse.
Sorry, only now that I have time to look into this. So what we are going to do before implementing the behaviour for resolve(strict=False) is to change the behaviour of resolve(strict=True) from --canonicalize-existing to --canonicalize? Is there any time left because we are in RC1 already? Should we postpone it to 3.5? But then, we'll have backward compatibility problem.
participants (3)
-
Antoine Pitrou -
Serhiy Storchaka -
Vajrasky Kok