Re: [Python-Dev] Improvements for Pathlib

2014-11-10 Thread Wolfgang Langner 
Hi,

some background about my pathlib usage.
I use the backported version of pathlib and tried to replace the usage of
path.py (also widely used library).

Some features part of path.py missing in pathlib:

- expanduser, expandvars, I have to use the os functions to do this.
  It is possible but better if this is part of pathlib.

- shutil stuff, as noted below

- dirs, and files from path.py. I often had to traverse a directory.
  I know this is possible with a generator. But It is so often needed that I
  missed this. Simple dirs(pattern) and files(pattern) is enough. With support
  for "**" as recursion.

Pathlib is a great library and it was good to add it to the standard lib.
Now it is time to improve it further.


On 08.11.2014 16:46, Ionel Cristian Mărieș wrote:
> Hello,
> 
> In the current incarnation Pathlib is missing some key features I need in my
> usecases. I want to contribute them but i'd like a bit of feedback on the new
> api before jumping to implementation.
> 
> The four things I need are:
> 
> #1. A context manager for temporary files and dirs (that cleans everything up
> on exit). Eg:
> 
> with pathlib.TmpDir(suffix='', prefix='') as tmp:
>   assert isinstance(tmp, pathlib.Path)
> 
> with pathlib.TmpFile(suffix='', prefix='') as tmp:
>   assert isinstance(tmp, pathlib.Path)

Good idea, but we should better add path support to tempfile module.

> #2. A context manager for changing working directory (that switches to the old
> cwd on exit). Eg:
> 
> with path.cd ():
>  assert os.getcwd() == path

Also useful. Even if the state is global. But has to be noted in documentation.

> #
> ​3​
> . Shutil-like features:
> 
> - copy_file
> - copy_dir (or copy_tree?)
> - copy (does copy_dir or copy_file depending on what the source is. How to
> handle symlinks?)
> - rm_dir (or rm_tree? Also, this would be required for the TmpDir path).

I also often needed this.

Thanks for bringing this up.


Regards,

Wolfgang



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improvements for Pathlib

2014-11-10 Thread Ionel Cristian Mărieș 
On Saturday, November 8, 2014, Xavier Morel  wrote:

>
>
> Why would pathlib need to provide this when tempfile already does?
>
>   with tempfile.NamedTemporaryFile(prefix='') as f:
>   tmp = pathlib.Path(f.name)
>
>   with tempfile.TemporaryDirectoryDirectory(prefix='') as d:
>   tmp = pathlib.Path(d.name)
>
> For the same reason pathlib provides path manipulation functionality while
os.path already does: a cohesive and more convenient api. In other words, I
want to have less calls and variables around (less room for errors, less
visual bloat), and this is such a common pattern it's worth supporting it
in pathlib.



-- 

Thanks,
-- Ionel M.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] pathlib difference to the backport

2014-11-10 Thread Ionel Cristian Mărieș 
Hey,

It appears there's a peculiar difference between the pathlib in the 3.4
branch and the one on bitbucket: cpython's pathlib.Path implements a no-op
context manager interface. What's the purpose of that? It's also
inconsistent, stat and all the methods that depend on stat do not implement
the "is closed check" (raise ValueError if __exit__ was already called).

Can anyone explain?

Thanks,
-- Ionel M.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improvements for Pathlib

2014-11-10 Thread Ionel Cristian Mărieș 
I disagree, having pathlib support in just one place in stdlib is in fact
what's really inconsistent. Also, I'm pretty sure that sprinkling pathlib
support all over the stdlib isn't going to be pretty.


Thanks,
-- Ionel M.

On Sun, Nov 9, 2014 at 12:06 AM, Xavier Morel 
wrote:

> On 2014-11-08, at 20:02 , Ionel Cristian Mărieș 
> wrote:
> > On Saturday, November 8, 2014, Xavier Morel 
> wrote:
> >
> > Why would pathlib need to provide this when tempfile already does?
> >
> >   with tempfile.NamedTemporaryFile(prefix='') as f:
> >   tmp = pathlib.Path(f.name)
> >
> >   with tempfile.TemporaryDirectoryDirectory(prefix='') as d:
> >   tmp = pathlib.Path(d.name)
> >
> > For the same reason pathlib provides path manipulation functionality
> while os.path already does: a cohesive and more convenient api. In other
> words, I want to have less calls and variables around (less room for
> errors, less visual bloat), and this is such a common pattern it's worth
> supporting it in pathlib.
>
> But now you've got two different places for tempfiles depending whether
> you want them to have an fs path or not. And the API isn't even more
> convenient when it comes to tempfiles, only to tempdir. Which could be
> fixed just as easily by adding a `path` attribute to
> tempfile.TemporaryDirectory.
>
> On 2014-11-08, at 21:41 , Ethan Furman  wrote:
> > On 11/08/2014 10:46 AM, Xavier Morel wrote:
> >> On 2014-11-08, at 16:46 , Ionel Cristian Mărieș wrote:
> >>>
> >>> In the current incarnation Pathlib is missing some key features I need
> in
> >>> my usecases. I want to contribute them but i'd like a bit of feedback
> on
> >>> the new api before jumping to implementation.
> >
> >>> #1. A context manager for temporary files and dirs (that cleans
> everything
> >>> up on exit).
> >>
> >> Why would pathlib need to provide this when tempfile already does?
> >
> > Because tempfile doesn't accept PathLib instances?
>
> Which can be fixed by adding support for `dir` being a Path in mkstemp,
> mktemp and mkdtemp.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/contact%40ionelmc.ro
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pathlib difference to the backport

2014-11-10 Thread Antoine Pitrou 
On Mon, 10 Nov 2014 13:45:57 +0200
Ionel Cristian Mărieș  wrote:
> Hey,
> 
> It appears there's a peculiar difference between the pathlib in the 3.4
> branch and the one on bitbucket: cpython's pathlib.Path implements a no-op
> context manager interface. What's the purpose of that?

Hum... That's a remnant of the various pathlib prototypes, where this
was used for the openat()-based implementation. It should probably be
removed.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pathlib difference to the backport

2014-11-10 Thread Ionel Cristian Mărieș 
Speaking of that, shouldn't pathlib have support for dir_fd?


Thanks,
-- Ionel M.

On Mon, Nov 10, 2014 at 6:53 PM, Antoine Pitrou  wrote:

> On Mon, 10 Nov 2014 13:45:57 +0200
> Ionel Cristian Mărieș  wrote:
> > Hey,
> >
> > It appears there's a peculiar difference between the pathlib in the 3.4
> > branch and the one on bitbucket: cpython's pathlib.Path implements a
> no-op
> > context manager interface. What's the purpose of that?
>
> Hum... That's a remnant of the various pathlib prototypes, where this
> was used for the openat()-based implementation. It should probably be
> removed.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/contact%40ionelmc.ro
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com