<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 7 May 2018 at 13:33, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Spit-balling: how about __filepath__ as a<br>
lazily-created-on-first-access pathlib.Path(__file__)?<br>
<br>
Promoting os.path stuff to builtins just as pathlib is emerging as<br>
TOOWTDI makes me a bit uncomfortable.<br></blockquote><div><br></div><div>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.<br><br>While lazy imports could likely help with the import time problem (since 6.5 of those milliseconds are from importing fnmatch), I think there's also a legitimate argument for a two tier system here, where we say "If you can't handle your filesystem manipulation task with just open, dirname, abspath, and joinpath, then reach for the higher level pathlib abstraction".<br><br></div><div>Cheers,<br></div><div>Nick.</div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>