On Wed, Jan 25, 2017 at 12:25 AM, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> I'm just going to let fly with the +1s and -1s, don't take them too > seriously, they're basically impressionistic (I'm not a huge user of > pathlib yet). > > Todd writes: > > > So although the names are tentative, perhaps there could be a > "fullsuffix" > > property to return the extensions as a single string, > > -0 '.'.join(p.suffixes) vs. p.fullsuffix? TOOWTDI says no. I > also don't really see the use case. > > The whole point of pathlib is to provide convenience functions for common path-related operations. It is full of methods and properties that could be implemented other ways. Dealing with multi-part extensions, at least for me, is extremely common. A ".tar.gz" file is not the same as a ".tar.bz2" or a ".svg.gz". When I want to find a ".tar.gz" file, having to deal with the ".tar" and ".gz" parts separately is nothing but a nuisance. If I want to find and extract ".rar" files, I don't want ".part1.rar" files, ".part2.rar" files, and so on. So for me dealing with the extension as a single unit, rather than individual parts, is the most common approach. > > a "nosuffix" extension to return the path without any extensions, > > +1 (subject to name bikeshedding) .suffixes itself is kinda > useless without this, and you shouldn't have to roll your own > > Do you propose to return a Path or a str here? > I intend it to behave as much as possible like the existing "stem" property, so a string. > > > and a "with_suffixes" method that replaces all the suffix and can > > accept multiple arguments (which would then be joined to create the > > extensions). > > Do you propose to return a Path or a str here? +1 for a Path, +0 for > a str. > It is intended to behave as much as possible like the existing "with_suffix" method, so a Path. > > Second, for methods like "rename" and "replace", it would be nice if > there > > was an "exist_ok" argument that defaults to "True" to allow for safe > > renaming. > > -1 I don't see how this is an improvement. If it would raise if > exist_ok == False, then > > try: > p.rename(another_p, exist_ok=False) > except ExistNotOKError: > take_evasive_action(p) > > doesn't seem like a big improvement over > > if p.exists(): > take_evasive_action(p) > else: > p.rename(another_p) > > And if it doesn't raise, then the action just silently fails? > > As Ed said, this can lead to race conditions. Something could happen after you check "exists". Also, the "mkdir" method already has an "exist_ok" argument, and the "open" function has the "x" flag to raise an exception if the file already exists. It seems like a major omission to me that there are safe ways to make files and safe ways to make directories, but no safe way to move files or directories. > Name bikeshedding: IIRC, if an argument is essentially always going to > be one of a small number of literals, Guido strongly prefers a new > method (eg, rename_safely). > > File and directory handling is already full of flags like this. This argument was taken verbatim from the existing "mkdir" method for consistency. > > > Fourth, for the "is_*" methods, it would be nice if there was a "strict" > > argument that would raise an exception if the file or directory doesn't > > exist. > > -1 That seems weird in a library intended for the syntactic > manipulation of uninterpreted paths (even though this is a semantic > operation). TOOWTDI and EIBTI, as well. For backward compatibility, > strict would have to default to False. > > First, these methods only exist for "concrete" paths, which are explicitly intended for use in I/O operations. Second, as before, this argument is taken from another method. In this case, the "resolve" method has a "strict" argument. Any other approach suffers from the same race conditions as "rename" and "replace", and again it seems weird that resolving a path can be done safely but testing it can't be. And yes, the argument would have to default to "False". All of my suggestions are intended to be completely backwards-compatible. I don't see that as a problem, though.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
