On 7 May 2018 at 14:33, Nathaniel Smith <n...@pobox.com> wrote:
> On Sun, May 6, 2018 at 8:47 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 7 May 2018 at 13:33, Nathaniel Smith <n...@pobox.com> wrote:
> >>
> >> Spit-balling: how about __filepath__ as a
> >> lazily-created-on-first-access pathlib.Path(__file__)?
> >>
> >> Promoting os.path stuff to builtins just as pathlib is emerging as
> >> TOOWTDI makes me a bit uncomfortable.
> >
> > pathlib *isn't* TOOWTDI, since it takes almost 10 milliseconds to import
> it,
> > and it introduces a higher level object-oriented abstraction that's
> > genuinely distracting when you're using Python as a replacement for shell
> > scripting.
>
> Hmm, the feedback I've heard from at least some folks teaching
> intro-python-for-scientists is like, "pathlib is so great for
> scripting that it justifies upgrading to python 3".
>
> How is
>
> data_path = __filepath__.parent / "foo.txt"
>
> more distracting than
>
> data_path = joinpath(dirname(__file__), "foo.txt")
>
Fair point :)
In that case, perhaps the right answer here would be to adjust the opening
examples section in the pathlib docs, showing some additional common
operations like:
_script_dir = Path(__file__).parent
_launch_dir = Path.cwd()
_home_dir = Path.home()
And perhaps in a recipes section:
def open_file_from_dir(dir_path, rel_path, *args, **kwds):
return open(Path(dir_path) / rel_path, *args, **kwds)
(Now that open() accepts path objects natively, I'm inclined to recommend
that over the pathlib-specific method spelling)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
