On Sat, Mar 17, 2018 at 10:42 AM, George Fischhof wrote:
>
> All functions from os module accept path-like objects,
> and none of the shutil functions.
shutil indirectly supports __fspath__ paths via os and os.path. One
exception is shutil.disk_usage() on Windows, which only
On Tuesday, 20 March 2018 16:22:57 GMT Brett Cannon wrote:
> On Mon, 19 Mar 2018 at 18:08 Chris Barker wrote:
> > [SNIP]
> > PS: does shutil really still not work with Path objects? aarrgg!
>
> Did you verify this or are you just guessing? If this is true then file a
> bug
On Tue, Mar 20, 2018 at 4:23 PM Brett Cannon wrote:
>
> > "justify the individual methods" and yet no one has done that yet, so
> any discussion other than trying to meet that need is not helping to move
> anything forward.
>
My intent was, and still is, to encourage just that.
On Mon, 19 Mar 2018 at 18:08 Chris Barker wrote:
> [SNIP]
> PS: does shutil really still not work with Path objects? aarrgg!
>
Did you verify this or are you just guessing? If this is true then file a
bug and optionally submit a patch. Saying "aarrgg" doesn't fix the
On Tue, Mar 20, 2018 at 4:25 AM, Nathaniel Smith wrote:
> On Tue, Mar 20, 2018 at 1:03 AM, Wes Turner wrote:
> > I added trio to the comparison table
> > (Things are mostly just async-wrapped,
> > though pathlib_not_trio does show a few missing methods?).
>
On Tue, Mar 20, 2018 at 1:03 AM, Wes Turner wrote:
> I added trio to the comparison table
> (Things are mostly just async-wrapped,
> though pathlib_not_trio does show a few missing methods?).
trio.Path is an automatically generated, exact mirror of pathlib.Path,
so I don't
I added trio to the comparison table
(Things are mostly just async-wrapped,
though pathlib_not_trio does show a few missing methods?).
https://github.com/westurner/pyfilemods/issues/2
https://github.com/westurner/pyfilemods/blob/master/README.rst#attr-table
== == === ==
On Sun, Mar 18, 2018 at 10:53 PM, Greg Ewing
wrote:
>
> The functions in os are thin wrappers around system calls,
>
exactly -- and this is a very old legacy from way back. Modern Python users
should not have to concern themselves with whether something they want to
On Mon, Mar 19, 2018 at 9:59 AM, Terry Reedy wrote:
> I am convinced that *some* people, especially but not limited to newbies,
> find the current situation confusing and less than optimal. I am also
> pretty convinced that the idea of dumping a copy of everything into pathlib
On Sun, 18 Mar 2018 at 20:37 Nathaniel Smith wrote:
> On Sun, Mar 18, 2018 at 4:58 AM, George Fischhof
> wrote:
> > Of course several details could be put into it, but I think it would
> better
> > to let the developers decide the details, because they know
On 2018-03-18 10:55, Paul Moore wrote:
Should Path() have methods to access all file operations?
No, (Counterexample, having a Path operation to set Windows ACLs for a path).
Agreed, not a big fan of everything filesystem-related in pathlib, simply
because it doesn't read well. Having
On 3/19/2018 11:31 AM, Rhodri James wrote:
On 18/03/18 11:58, George Fischhof wrote:
it seems for me that the welcoming of this proposal is rather positive
than
not.
I think you may have observer bias :-)
Or, as often happens, George is making too much of a biased sample of
opinions --
On 18/03/18 11:58, George Fischhof wrote:
it seems for me that the welcoming of this proposal is rather positive than
not.
I think you may have observer bias :-)
As far as I am concerned you have yet to make a convincing case that
there is a problem, never mind that your solution is
Here's a comparison table of os, os.path, shutil, pathlib, and path.py.
The full version is at
https://github.com/westurner/pyfilemods (README.rst)
and at
https://westurner.github.io/pyfilemods.
I ran a few set intersections and went ahead and
wrote a report to compare function/method signatures
On 03/19/18 09:17, Stephen J. Turnbull wrote:
Nathaniel Smith writes:
> Similarly, it's hard to explain why we have Path.mkdir but not
> Path.makedirs
So what? Let's fix that. As you propose:
> (maybe it should be Path.mkdir(include_parents=True)
> is fine, although that default seems
Jason Maldonis writes:
> So we have two "high-level" libraries (pathlib and shutil)
pathlib is currently "low-level" as I understand the word. The only
complex things it does are resolving and globbing, which are
reasonable things to do with a Path's target object. Everything else
is either a
Nathaniel Smith writes:
> On Sat, Mar 17, 2018 at 10:15 AM, Stephen J. Turnbull
> wrote:
> > (5) perform operations on several objects denoted by Paths at once
> > (copy and its multiple operand variants),
>
> Sure it does: Path.rename and
On Sun, Mar 18, 2018 at 4:58 AM, George Fischhof wrote:
> Of course several details could be put into it, but I think it would better
> to let the developers decide the details, because they know the environment
> and the possibilities.
That's not how PEPs work :-). Someone
On Sun, Mar 18, 2018 at 4:16 PM, George Fischhof wrote:
> Hi Jason,
>
> the status of os and shutil became this because of C functions in
> implementation (I got something similar answer before)
> ...
>
> What do you think, what would be a good way to solve this
> - add stuff
Jason Maldonis wrote:
In python, `os` and `shutil` are currently the low-level modules, and it
stands to reason that we might consider combining these somehow
(although I'm assuming that there was a good reason not to in the first
place
The functions in os are thin wrappers around system
On Sun, Mar 18, 2018 at 4:16 PM, George Fischhof wrote:
> Hi Jason,
>
> the status of os and shutil became this because of C functions in
> implementation (I got something similar answer before)
> ...
>
> What do you think, what would be a good way to solve this
> - add stuff
Hi Jason,
the status of os and shutil became this because of C functions in
implementation (I got something similar answer before)
...
What do you think, what would be a good way to solve this
- add stuff from os to shutil
- add stuff from os and shutil to pathlib
- create a new module on top of
>
> Surely shutil is a *high* level modules.
> os is a low level module that shutil builds on.
> Adding the missing pieces to shutil would make it the place to go to do
> file operations.
> Pity its not called filelib.
>
Gotcha, thank you! shutil being a high level library complicates things...
> On 18 Mar 2018, at 17:50, Jason Maldonis wrote:
>
> Maybe this is obvious or I am missing something crucial, but I'm surprised
> that this hasn't been discussed yet:
>
> From a user perspective, imo the problem is that users currently need three
> modules (pathlib,
On 18 March 2018 at 14:44, Barry Scott wrote:
> It seems that the main quest to answer first is this.
>
> Should Path() have methods to access all file operations?
No, (Counterexample, having a Path operation to set Windows ACLs for a path).
> Maybe it was a mistake to
> On 18 Mar 2018, at 11:58, George Fischhof wrote:
>
> Hi Folks,
>
> it seems for me that the welcoming of this proposal is rather positive than
> not.
I think that is up for debate.
>
> Of course several details could be put into it, but I think it would better
> to
Maybe this is obvious or I am missing something crucial, but I'm surprised
that this hasn't been discussed yet:
>From a user perspective, imo the problem is that users currently need three
modules (pathlib, os, and shutil) to have a nice interface for working
with, copying, and removing files. In
It seems that the main quest to answer first is this.
Should Path() have methods to access all file operations?
Maybe it was a mistake to add the ones that are already there.
Especially in light of the fspath protocol that now exists.
If yes proceed to details the methods and their semantics.
On 18 March 2018 at 04:41, Nathaniel Smith wrote:
> My understanding is that the point of Path is to be a convenient,
> pleasant-to-use mechanism for accessing common filesystem operations.
> And it does a pretty excellent job of that. But it seems obvious to me
> that it's still
On 17 March 2018 at 22:49, George Fischhof wrote:
>>>
>>> * os.truncate
>>>
>>> * shutil.copyfileobj
>>>
>>>
>>> This function does not take paths as arguments. I guess it does not belong
>>> here.
>
> No path, it is true (right now), but it has sense to have this
Hi Folks,
it seems for me that the welcoming of this proposal is rather positive than
not.
Of course several details could be put into it, but I think it would better
to let the developers decide the details, because they know the environment
and the possibilities.
The name of the functions and
17.03.18 19:15, Stephen J. Turnbull пише:
As far as I can recall, pathlib is intended from the beginning to
(1) represent paths in hierarchical local filesystems as Paths,
(2) manipulate individual Paths in various ways consistent with the
semantics of a hierarchal filesystem, and
(3) offer
2018-03-18 9:05 GMT+01:00 Nick Coghlan :
> On 16 March 2018 at 03:15, Chris Angelico wrote:
>
>> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof
>> wrote:
>> >
>> >
>> > " if new file functions are added, they will go only in pathlib,
2018-03-18 5:41 GMT+01:00 Nathaniel Smith :
> On Sat, Mar 17, 2018 at 10:15 AM, Stephen J. Turnbull
> wrote:
> > (5) perform operations on several objects denoted by Paths at once
> > (copy and its multiple operand variants),
>
> Sure it
> On 17 Mar 2018, at 22:49, George Fischhof wrote:
>
>
>
> 2018. márc. 17. 21:34 ezt írta ("Barry" ):
>
>
>> On 17 Mar 2018, at 10:42, George Fischhof wrote:
>>
>> Hi folks,
>>
>> I added the list of functions to the
On 16 March 2018 at 03:15, Chris Angelico wrote:
> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof
> wrote:
> >
> >
> > " if new file functions are added, they will go only in pathlib,
> > which makes pathlib effectively mandatory;"
> > Yes but I think
On Sat, Mar 17, 2018 at 10:15 AM, Stephen J. Turnbull
wrote:
> (5) perform operations on several objects denoted by Paths at once
> (copy and its multiple operand variants),
Sure it does: Path.rename and Path.replace. I know why rename and copy
have
2018. márc. 17. 21:34 ezt írta ("Barry" ):
On 17 Mar 2018, at 10:42, George Fischhof wrote:
Hi folks,
I added the list of functions to the proposal, here is the new version.
George
PEP:
Title: Pathlib Module Should Contain All File
> On 17 Mar 2018, at 10:42, George Fischhof wrote:
>
> Hi folks,
>
> I added the list of functions to the proposal, here is the new version.
>
> George
>
>
>
>
> PEP:
> Title: Pathlib Module Should Contain All File Operations
> Author: George Fischhof
> Status:
George Fischhof writes:
> It seems that the original idea was something like for my idea.
> Just it not finished yet,
Antoine (author and maintainer of pathlib) is not the kind of
developer who leaves things unfinished. In PEP 428, there's a hint
that some shutil functionality could be added,
Hi folks,
I added the list of functions to the proposal, here is the new version.
George
PEP:
Title: Pathlib Module Should Contain All File Operations
Author: George Fischhof
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Mar-2018
Python-Version: 3.8
2018-03-17 7:18 GMT+01:00 Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:
> Joonas Liik writes:
>
> > then it might be an acceptable compromise to have yet another...
>
> "There should be one-- and preferably only one -- obvious way to do it."
>
> The obvious way is to use the
Joonas Liik writes:
> then it might be an acceptable compromise to have yet another...
"There should be one-- and preferably only one -- obvious way to do it."
The obvious way is to use the existing stdlib modules. So
> package that just imports os, pathlib, shutil etc and re-exports
>
If there it is desireable to have pathlib used to represent paths that do
not map directly to the filesystem..
then it might be an acceptable compromise to have yet another... package
that just imports os, pathlib, shutil etc and re-exports all relevant
functions.
i mean we are talking about
On Fri, Mar 16, 2018 at 4:48 AM, Antoine Pitrou wrote:
> On Fri, 16 Mar 2018 04:15:11 +1100
> Chris Angelico wrote:
>> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof wrote:
>> >
>> >
>> > " if new file functions are added, they will
On Fri, 16 Mar 2018 04:15:11 +1100
Chris Angelico wrote:
> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof wrote:
> >
> >
> > " if new file functions are added, they will go only in pathlib,
> > which makes pathlib effectively mandatory;"
> > Yes but I
On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof wrote:
>
>
> " if new file functions are added, they will go only in pathlib,
> which makes pathlib effectively mandatory;"
> Yes but I think this part of the evolution: slowly everyone will shift to
> pathlib,
> and being
2018-03-13 13:17 GMT+01:00 Steven D'Aprano :
> On Mon, Mar 12, 2018 at 09:57:32PM +0100, George Fischhof wrote:
>
> > Right now we have several modules that contain functions related
> > to file-system operations mainly the os, pathlib and shutil.
> > For beginners it is
> On 12 Mar 2018, at 21:56, George Fischhof wrote:
>
>
>
> 2018-03-12 22:16 GMT+01:00 Paul Moore :
>> On 12 March 2018 at 20:57, George Fischhof wrote:
>> > Good day all,
>> >
>> > as it seemed to be a good idea, I wrote a PEP
On Mar 12, 2018 1:57 PM, "George Fischhof" wrote:
This PEP proposes pathlib module to be a centralized place for all
file-system related operations.
I'd find this useful for another reason that hasn't been mentioned yet:
having a single class collecting all the common/basic
On Tue, 13 Mar 2018 15:35:56 +
Rhodri James wrote:
> On 12/03/18 20:57, George Fischhof wrote:
> > Good day all,
> >
> > as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
> > contain file operations.
> >
> > Here is the draft. What do you think
On 12/03/18 20:57, George Fischhof wrote:
Good day all,
as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
contain file operations.
Here is the draft. What do you think about this?
I am mildly negative about this. In my copious spare time (ho ho) I
have been considering
On Mon, Mar 12, 2018 at 09:57:32PM +0100, George Fischhof wrote:
> Right now we have several modules that contain functions related
> to file-system operations mainly the os, pathlib and shutil.
> For beginners it is quite hard to remember where can he / she find
> a function (copy resides in
2018-03-12 22:16 GMT+01:00 Paul Moore :
> On 12 March 2018 at 20:57, George Fischhof wrote:
> > Good day all,
> >
> > as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
> > contain file operations.
> >
> > Here is the draft. What do you
On 12 March 2018 at 20:57, George Fischhof wrote:
> Good day all,
>
> as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
> contain file operations.
>
> Here is the draft. What do you think about this?
I don't know for certain what I think I feel about the
Good day all,
as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
contain file operations.
Here is the draft. What do you think about this?
BR,
George
---
PEP:
Title: Pathlib Module Should Contain All File Operations
Author: George Fischhof
56 matches
Mail list logo