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) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia