On 2014-11-08, at 20:02 , Ionel Cristian Mărieș <contact at ionelmc.ro> wrote: > On Saturday, November 8, 2014, Xavier Morel <python-dev at masklinn.net> 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 <ethan at stoneleaf.us> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4