Python 3 Feature Request: `pathlib` Use Trailing Slash Flag

`pathlib` trims trailing slashes by default, but certain packages require trailing slashes. In particular, `cx_Freeze.bdist_msi` option "directories" is used to build the package directory structure of a program and requires trailing slashes. Does anyone think it would be a good ide

Re: pathlib

;outside' research, eg StackOverflow, shows that > sub-classing pathlib is problematic, and quite possibly not part of the > design (this is repeating 'gossip' - I'm not going to try to justify the > comment or the claim). That said, last night my code sub-classin

Re: pathlib

> On 3 Oct 2019, at 13:04, Richard Damon wrote: > > I am not sure that Concrete is really the right term here, but the > beginning of the documentation for Pathlib does sort of define what it > means here: There is a need to describe three ideas. The PurePath The OS Spec

Re: pathlib

or incomplete, but I appreciate your efforts to straighten-out it (and > me)! My experience is that Concrete is generally thought of as the opposite of Abstract, you can make an object of a Concrete type, but not one of an Abstract type. That doesn't quite apply here as PurePath isn't

Re: pathlib

f it will come to that (having 'got past' > the original observation/issue, I'm concerned by .rename()'s silent > errors, for example). However, that 'outside' research, eg > StackOverflow, shows that sub-classing pathlib is problematic, and > quite possibly n

Re: pathlib

this time (and assuming that after two (separate) incidents dragging me away to solve other people's problems, I intend to stick with trying to get my head around pathlib - even if I have to sub-class it (which my reading shows is another 'can of worms'). So, 'reading' is

Re: pathlib

On 3/10/19 3:07 AM, Rhodri James wrote: On 02/10/2019 09:14, DL Neil via Python-list wrote: That said, it is one of the ways that a path can be shown to transition from some 'pure' state to become 'concrete'. However, A.N.Other has suggested that I might be mis-applying the word "concrete", s

Re: pathlib

L Neil via Python-list mailto:[email protected]>> wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. The term "concrete" is applied to Path(), PosixPath(), and WindowsPath() - whereas the others are differentiated with the p

Re: pathlib

:40, DL Neil via Python-list >>>>> wrote: >>>>> >>>>> Should pathlib reflect changes it has made to the file-system? >>>> >>>> I think it should not. >>> >>> The term "concrete" is applied to Path(), PosixPath(), and

Re: pathlib

On 02/10/2019 09:14, DL Neil via Python-list wrote: That said, it is one of the ways that a path can be shown to transition from some 'pure' state to become 'concrete'. However, A.N.Other has suggested that I might be mis-applying the word "concrete", so maybe not. On which topic, I went looki

Re: pathlib

to a file that didn't exist, however un-useful it may have been. At this time (and assuming that after two (separate) incidents dragging me away to solve other people's problems, I intend to stick with trying to get my head around pathlib - even if I have to sub-class it (which my reading

Re: pathlib

On 2/10/19 12:52 AM, Rhodri James wrote: On 01/10/2019 06:03, DL Neil via Python-list wrote: On 30/09/19 9:28 PM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. The term

Re: pathlib

On 01/10/2019 06:03, DL Neil via Python-list wrote: On 30/09/19 9:28 PM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. The term "concrete" is applied to Path(),

Re: pathlib

PurePath represents the name of (or the path to) a file, but a >>> Path represents the actual file. >>> >>> >>> ⁰ https://docs.python.org/3/library/pathlib.html >> >> I don't think it represents the actual file. If it did, equality would >&g

Re: pathlib

examines the rate of adoption for (open source) languages and libraries, the greatest influence is the presence/absence of quality tutorials - materials designed to encourage the building of congruent mental models! In this discussion we've heard people comparing pathlib with pr

Re: pathlib

On Tue, Oct 1, 2019 at 3:05 PM DL Neil via Python-list wrote: > BUT... Path() does keep track of changes in the file system for other > attributes! So, why not also name? Does it actually track changes? > Here's a code-snippet illustrating both of the above points: > >

Re: pathlib

On Tue, Oct 1, 2019 at 3:26 PM DL Neil via Python-list wrote: > > On 1/10/19 1:09 AM, Chris Angelico wrote: > > I don't think it represents the actual file. If it did, equality would > > be defined by samefile, NOT by the file name. > > > >>>> from path

Re: pathlib

On 1/10/19 3:21 AM, Dan Sommers wrote: On 9/30/19 8:40 AM, Barry Scott wrote:  >> On 30 Sep 2019, at 12:51, Dan Sommers <[email protected]> wrote:  >> On 9/30/19 4:28 AM, Barry Scott wrote:  >>>> On 30 Sep 2019, at 05:40, DL Neil via Python-list

Re: pathlib

On 1/10/19 1:40 AM, Barry Scott wrote: On 30 Sep 2019, at 12:51, Dan Sommers <[email protected]> wrote: On 9/30/19 4:28 AM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: Should pathlib reflect changes it has made to the file-system? I

Re: pathlib

l file. ⁰ https://docs.python.org/3/library/pathlib.html I don't think it represents the actual file. If it did, equality would be defined by samefile, NOT by the file name. from pathlib import Path import os open("file1", "w").close() os.link("file1", "file2

Re: pathlib

On 30/09/19 9:28 PM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. The term "concrete" is applied to Path(), PosixPath(), and WindowsPath() - whereas the

Re: pathlib

On 9/30/19 3:56 PM, Barry Scott wrote: On 30 Sep 2019, at 16:49, Dan Sommers <[email protected] > wrote: In the totality of a Path object that claims to represent paths to files, It represents string that *should* in most cases

Re: pathlib

> On 30 Sep 2019, at 16:49, Dan Sommers <[email protected]> > wrote: > > That's an interesting question. If you phrase the question like > that, then you're right: expecting a string to track the content > of a file is a mistake. > > In the totality of a Path object that

Re: pathlib

On 1/10/19 6:13 AM, Dan Sommers wrote: On 9/30/19 12:51 PM, Chris Angelico wrote: On Tue, Oct 1, 2019 at 1:51 AM Dan Sommers ... All I'm doing is defending the OP, who was surprised that renaming a file *using a Path instance* didn't reflect that operation *in that Path instance*.  I believe

Re: pathlib

On 9/30/19 12:51 PM, Chris Angelico wrote: On Tue, Oct 1, 2019 at 1:51 AM Dan Sommers <[email protected]> wrote: In the totality of a Path object that claims to represent paths to files, including the arguably troublesome read_bytes and write_bytes methods, and a rename method,

Re: pathlib

On Tue, Oct 1, 2019 at 1:51 AM Dan Sommers <[email protected]> wrote: > In the totality of a Path object that claims to represent paths > to files, including the arguably troublesome read_bytes and > write_bytes methods, and a rename method, however, it's not > unreasonable expect

Re: pathlib

On 9/30/19 10:33 AM, Barry Scott wrote: On 30 Sep 2019, at 14:20, Dan Sommers <[email protected] > wrote: That's the wording I read.  I inferred that "path-handling operations which don't actually access a filesystem" meant an obje

Re: pathlib

> On 30 Sep 2019, at 14:20, Dan Sommers <[email protected]> > wrote: > > That's the wording I read. I inferred that "path-handling operations > which don't actually access a filesystem" meant an object that didn't > necessarily represent an actual file, and that "provide meth

Re: pathlib

On 9/30/19 8:40 AM, Barry Scott wrote: > > >> On 30 Sep 2019, at 12:51, Dan Sommers <[email protected]> wrote: >> >> On 9/30/19 4:28 AM, Barry Scott wrote: >>>> On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: >>

Re: pathlib

> On 30 Sep 2019, at 12:51, Dan Sommers <[email protected]> > wrote: > > On 9/30/19 4:28 AM, Barry Scott wrote: >>> On 30 Sep 2019, at 05:40, DL Neil via Python-list >>> wrote: >>> Should pathlib reflect changes it has made to th

Re: pathlib

ocs.python.org/3/library/pathlib.html I don't think it represents the actual file. If it did, equality would be defined by samefile, NOT by the file name. >>> from pathlib import Path >>> import os >>> open("file1", "w").close() >>> os.link(

Re: pathlib

On 9/30/19 4:28 AM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. A Path() is the name of a file it is not the file itself. Why should it track changes in the file system

Re: pathlib

> On 30 Sep 2019, at 09:55, Peter Otten <[email protected]> wrote: > > DL Neil via Python-list wrote: > >> Should pathlib reflect changes it has made to the file-system? >> >> >> Sample code, below, shows pathlib identifying a data-file and

Re: pathlib

DL Neil via Python-list wrote: > Should pathlib reflect changes it has made to the file-system? > > > Sample code, below, shows pathlib identifying a data-file and then > renaming it. Yet, after the rename operation, pathlib doesn't recognise > its own change; where

Re: pathlib

> On 30 Sep 2019, at 05:40, DL Neil via Python-list > wrote: > > Should pathlib reflect changes it has made to the file-system? I think it should not. A Path() is the name of a file it is not the file itself. Why should it track changes in the file system for the name? Her

pathlib

Should pathlib reflect changes it has made to the file-system? Sample code, below, shows pathlib identifying a data-file and then renaming it. Yet, after the rename operation, pathlib doesn't recognise its own change; whereas the file system does/proves the change was actioned. $

Re: pathlib PurePosixPath

On Tue, Oct 10, 2017 at 11:18 AM, Tim Golden wrote: > On 2017-10-10 10:58, Chris Angelico wrote: >> On Tue, Oct 10, 2017 at 8:56 PM, Tim Golden wrote: >> >>> In fact its presence in that filename creates a (usually hidden) data >>> stream piggybacked onto that file which has the name "abc" into w

Re: pathlib PurePosixPath

On 2017-10-10 10:58, Chris Angelico wrote: On Tue, Oct 10, 2017 at 8:56 PM, Tim Golden wrote: My understanding of the document you linked to is that the colon still has special meaning, and thus you can't use it in arbitrary file names. In fact its presence in that filename creates a (usua

Re: pathlib PurePosixPath

On Tue, Oct 10, 2017 at 8:56 PM, Tim Golden wrote: >> My understanding of the document you linked to >> is that the colon still has special meaning, and thus you can't use it >> in arbitrary file names. > > > In fact its presence in that filename creates a (usually hidden) data stream > piggybacke

Re: pathlib PurePosixPath

On 2017-10-10 10:28, Chris Angelico wrote: On Tue, Oct 10, 2017 at 8:22 PM, Tim Golden wrote: On 2017-10-10 08:29, Chris Angelico wrote: On Tue, Oct 10, 2017 at 6:21 PM, Sayth Renshaw wrote: Hi How do I create a valid file name and directory with pathlib? When I create it using

Re: pathlib PurePosixPath

On Tue, Oct 10, 2017 at 8:22 PM, Tim Golden wrote: > On 2017-10-10 08:29, Chris Angelico wrote: >> >> On Tue, Oct 10, 2017 at 6:21 PM, Sayth Renshaw >> wrote: >>> >>> Hi >>> >>> How do I create a valid file name and directory with pathl

Re: pathlib PurePosixPath

On 2017-10-10 08:29, Chris Angelico wrote: On Tue, Oct 10, 2017 at 6:21 PM, Sayth Renshaw wrote: Hi How do I create a valid file name and directory with pathlib? When I create it using PurePosixPath I end up with an OSError due to an obvously invlaid path being created. You're on Wi

Re: pathlib PurePosixPath

On 2017-10-10 09:44, Sayth Renshaw wrote: > >>> Hi >>> >>> How do I create a valid file name and directory with pathlib? >>> >>> When I create it using PurePosixPath I end up with an OSError due to an >>> obvously invlaid path being cr

Re: pathlib PurePosixPath

Sayth Renshaw wrote: > Thanks. Updated the script. But shouldn't it create the file if it doesn't > exist? Which none of them will. > pathlib.PurePath(r'C:\Users\Sayth\Projects\results', file_name) > with open(result_path, 'a') as f: > f.write(data) > ##Output > File

Re: pathlib PurePosixPath

On 10/10/2017 08:44, Sayth Renshaw wrote: > >>> Hi >>> >>> How do I create a valid file name and directory with pathlib? >>> >>> When I create it using PurePosixPath I end up with an OSError due to an >>> obvously invlaid path being cr

Re: pathlib PurePosixPath

> > Hi > > > > How do I create a valid file name and directory with pathlib? > > > > When I create it using PurePosixPath I end up with an OSError due to an > > obvously invlaid path being created. > > You're on Windows. The rules for POS

Re: pathlib PurePosixPath

On Tue, Oct 10, 2017 at 6:21 PM, Sayth Renshaw wrote: > Hi > > How do I create a valid file name and directory with pathlib? > > When I create it using PurePosixPath I end up with an OSError due to an > obvously invlaid path being created. You're on Windows. The rule

pathlib PurePosixPath

Hi How do I create a valid file name and directory with pathlib? When I create it using PurePosixPath I end up with an OSError due to an obvously invlaid path being created. import pathlib for dates in fullUrl: # print(dates) time.sleep(0.3) r = requests.get(dates) data

Re: Why does pathlib not have is_readable() & things like that?

On 2016-04-29, eryk sun wrote: > On Fri, Apr 29, 2016 at 6:51 AM, Jussi Piitulainen > wrote: >> Adam Funk writes: >>> On 2016-04-28, Grant Edwards wrote: >> Or just do os.access("directory/where/you/want/to/open/a/file",os.W_OK) >>> >>> That's what I'm doing now, but I prefer to give the user

Re: Why does pathlib not have is_readable() & things like that?

On Fri, Apr 29, 2016 at 6:51 AM, Jussi Piitulainen wrote: > Adam Funk writes: >> On 2016-04-28, Grant Edwards wrote: > >>> Or just do os.access("directory/where/you/want/to/open/a/file",os.W_OK) >> >> That's what I'm doing now, but I prefer to give the user the error >> message early on. > > Then

Re: Why does pathlib not have is_readable() & things like that?

Adam Funk writes: > On 2016-04-28, Grant Edwards wrote: >> >> Then open the output file before you do the GET. > > I guess I could, but fetching the data actually involves a whole lot > of GET requests (the first one includes cross-references to the URLs > where the rest of the data is found), som

Re: Why does pathlib not have is_readable() & things like that?

On 2016-04-28, Grant Edwards wrote: > On 2016-04-28, Adam Funk wrote: >> On 2016-04-26, Random832 wrote: >> >>> On Tue, Apr 26, 2016, at 09:30, Adam Funk wrote: >>>> I recently discovered pathlib in the Python 3 standard library, & find >>>

Re: Why does pathlib not have is_readable() & things like that?

On 2016-04-28, Adam Funk wrote: > On 2016-04-26, Random832 wrote: > >> On Tue, Apr 26, 2016, at 09:30, Adam Funk wrote: >>> I recently discovered pathlib in the Python 3 standard library, & find >>> it very useful, but I'm a bit surprised that it doesn&#x

Re: Why does pathlib not have is_readable() & things like that?

Adam Funk writes: > On 2016-04-26, Random832 wrote: > >> On Tue, Apr 26, 2016, at 09:30, Adam Funk wrote: >>> I recently discovered pathlib in the Python 3 standard library, & find >>> it very useful, but I'm a bit surprised that it doesn't offer things

Re: Why does pathlib not have is_readable() & things like that?

On 2016-04-26, Random832 wrote: > On Tue, Apr 26, 2016, at 09:30, Adam Funk wrote: >> I recently discovered pathlib in the Python 3 standard library, & find >> it very useful, but I'm a bit surprised that it doesn't offer things >> like is_readable() and is_wr

Re: Why does pathlib not have is_readable() & things like that?

On 2016-04-26, Steven D'Aprano wrote: > On Tue, 26 Apr 2016 11:30 pm, Adam Funk wrote: >> I've been improvising with things like this: >> >> import pathlib, os >> >> path = pathlib.Path('some/directory') >> writable = os.access(str(pat

Re: Why does pathlib not have is_readable() & things like that?

On Tue, 26 Apr 2016 11:30 pm, Adam Funk wrote: > I recently discovered pathlib in the Python 3 standard library, & find > it very useful, but I'm a bit surprised that it doesn't offer things > like is_readable() and is_writable. Is there a good reason for that? Maybe no

Re: Why does pathlib not have is_readable() & things like that?

On Tue, Apr 26, 2016, at 09:30, Adam Funk wrote: > I recently discovered pathlib in the Python 3 standard library, & find > it very useful, but I'm a bit surprised that it doesn't offer things > like is_readable() and is_writable. Is there a good reason for that? Well, o

Why does pathlib not have is_readable() & things like that?

I recently discovered pathlib in the Python 3 standard library, & find it very useful, but I'm a bit surprised that it doesn't offer things like is_readable() and is_writable. Is there a good reason for that? I've been improvising with things like this: import pathlib, os

Re: Simplest/Idiomatic way to count files in a directory (using pathlib)

On 6/22/2015 9:32 PM, Paul Rubin wrote: Travis Griggs writes: The following seems to obtuse/clever for its own good: return sum(1 for _ in self.path.iterdir()) I disagree. For one who understands counting and Python, this is a direct way to define the count of a finite iterable. A fun

Re: Simplest/Idiomatic way to count files in a directory (using pathlib)

Travis Griggs wrote: > Subject nearly says it all. > > If i’m using pathlib, what’s the simplest/idiomatic way to simply count > how many files are in a given directory? > > I was surprised (at first) when > > len(self.path.iterdir()) > > I don’t say anythin

Re: Simplest/Idiomatic way to count files in a directory (using pathlib)

I use len(list(self.path.iterdir())) You get an extra list created in there. Do you care? Laura -- https://mail.python.org/mailman/listinfo/python-list

Re: Simplest/Idiomatic way to count files in a directory (using pathlib)

Travis Griggs writes: > The following seems to obtuse/clever for its own good: > return sum(1 for _ in self.path.iterdir()) I've generally done something like that. I suppose it could be added to itertools. -- https://mail.python.org/mailman/listinfo/python-list

Re: Simplest/Idiomatic way to count files in a directory (using pathlib)

On Mon, Jun 22, 2015 at 4:33 PM, Travis Griggs wrote: > > > Subject nearly says it all. > > If i’m using pathlib, what’s the simplest/idiomatic way to simply count how > many files are in a given directory? > > I was surprised (at first) when > >len(self.p

Re: Simplest/Idiomatic way to count files in a directory (using pathlib)

Subject nearly says it all. If i’m using pathlib, what’s the simplest/idiomatic way to simply count how many files are in a given directory? I was surprised (at first) when len(self.path.iterdir()) didn’t work. I don’t see anything in the .stat() object that helps me. I could of course

Simplest/Idiomatic way to count files in a directory (using pathlib)

Subject nearly says it all. If i’m using pathlib, what’s the simplest/idiomatic way to simply count how many files are in a given directory? I was surprised (at first) when len(self.path.iterdir()) I don’t say anything on the in the .stat() object that helps me. I could of course do the

Re: pathlib type error

On Sat, Jan 3, 2015 at 11:06 PM, Chris Angelico wrote: > On Sat, Jan 3, 2015 at 10:55 PM, Georg Grafendorfer > wrote: >> I'm using Debian 8 Jessie on an AMD64 machine. >> Getting this error: >> >> ~$ python3 >> Python 3.4.2 (default, Oct 8 2014, 10:45:20) >> [GCC 4.9.1] on linux > > Unable to re

Re: pathlib type error

;, "credits" or "license" for more information. >>>> from pathlib import Path >>>> p = Path("/etc") >>>> q = p / "init.d" > Traceback (most recent call last): > File "", line 1, in > TypeError: unsupported operan

pathlib type error

Hi I'm using Debian 8 Jessie on an AMD64 machine. Getting this error: ~$ python3 Python 3.4.2 (default, Oct 8 2014, 10:45:20) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from pathli

Re: is pathlib Path.resolve working as intended?

On Wed, Dec 24, 2014, at 09:09, Chris Cioffi wrote: > PS: For those who are curious, the 2 issues that seemed to hold things > up the most are non-Unix systems (Windows) and how to handle when there > is no home directory. Posix only says that the results are undefined. What did they end up do

Re: is pathlib Path.resolve working as intended?

d that the pathlib module was even put in provisionally. I do like how it works, however. Paths as objects and not strings! Its a beautiful idea, just not 100% complete. PS: For those who are curious, the 2 issues that seemed to hold things up the most are non-Unix systems (Windows) and how to h

Re: is pathlib Path.resolve working as intended?

>>> p.resolve() ... FileNotFoundError: [Errno 2] No such file or directory: '/Users/chris/~' I've not used the pathlib module yet, but poked through the documentation. Oddly enough, I saw no mention of "~". The doc for the resolve method only mentions resolving

is pathlib Path.resolve working as intended?

Ok, I'm guessing I'm doing something wrong, but I can't see what. I'm playing around with pathlib (Python 3.4.2) on Mac OSX, Yosemite. In the past I've used os.path.expanduser() to expand paths with ~. Based on the description, I would have expected .resolve to do th

Re: [ANN] pathlib 1.0.1

On Wednesday, September 3, 2014 11:58:47 AM UTC-4, Antoine Pitrou wrote: > > pathlib offers a set of classes to handle filesystem paths. How does it differ from path.py? -- https://mail.python.org/mailman/listinfo/python-list

[ANN] pathlib 1.0.1

Hello, I am announcing the release of pathlib 1.0.1. This version makes pathlib Python 2.6-compatible. Note that 2.6 compatibility may not have been as well tested as more recent Python versions (especially on non-Unix platforms). As a reminder, the standalone (PyPI) version of pathlib will

Re: [ANN] pathlib 1.0

Oh, and of course it is published on PyPI: https://pypi.python.org/pypi/pathlib/ Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list

[ANN] pathlib 1.0

Hello, I am announcing the release of pathlib 1.0. This version brings pathlib up to date with the official Python 3.4 release, and also fixes a couple of 2.7-specific issues. Detailed changelog can be found further below. In the future, I expect the standalone (PyPI) version of pathlib to

ANN: pathlib 0.97 released

Hello, As you may know, pathlib has recently been accepted for inclusion into the Python 3.4 standard library. You can view the new module's documentation here: http://docs.python.org/dev/library/pathlib.html As part of the inclusion process, many API changes were done to the original pa

ANN: pathlib 0.8

pathlib 0.8 has been released at https://pypi.python.org/pypi/pathlib/ Changes --- - Add PurePath.name and PurePath.anchor. - Add Path.owner and Path.group. - Add Path.replace(). - Add Path.as_uri(). - Issue #10: when creating a file with Path.open(), don't set the executable

ANN: pathlib 0.7

Hello, pathlib 0.7 has been released with the following changes: - Add '**' (recursive) patterns to Path.glob(). - Fix openat() support after the API refactoring in Python 3.3 beta1. - Add a *target_is_directory* argument to Path.symlink_to() pathlib offers a set of classes