On 7 May 2018 at 14:33, Nathaniel Smith <njs@pobox.com> wrote:
On Sun, May 6, 2018 at 8:47 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
> On 7 May 2018 at 13:33, Nathaniel Smith <njs@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)


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia