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 has to do the work of
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 from os to shutil
>
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 call
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 from os to shutil
>
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...
So
> 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, os, and shutil) to have
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 add the ones that are alre
> 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 let the developers de
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.
I
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 missing a number
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 function
> among the othe
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,
>> > which makes pathlib effectively mandatory;"
>> > Yes
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 does: Path.rename and Path.replace. I know why rename a
> 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 proposal, here is the new version.
>>
>> George
>>
>>
>>
>>
>> PEP
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 this part of the evolution: slowly ever
19 matches
Mail list logo