<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 March 2018 at 03:15, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof <<a href="mailto:george@fischhof.hu">george@fischhof.hu</a>> wrote:<br>
><br>
><br>
> " if new file functions are added, they will go only in pathlib,<br>
>   which makes pathlib effectively mandatory;"<br>
> Yes but I think this part of the evolution: slowly everyone will shift to<br>
> pathlib,<br>
> and being mandatory is true for the current status as well: if you need a<br>
> function, you need the module.<br>
> Right now if you wan to execute some file operations, you need os plus<br>
> shutil, because the half of the<br>
> functions are in one of them, the other half is in the other module<br>
<br>
</span>The os module is cheap; pathlib has a definite cost. If every file<br>
operation goes through pathlib</blockquote><div><br></div><div>Keep in mind that the `os` layer will never go away: `pathlib` still needs a lower level API to call to *do the work* of actually interacting with the underlying operating system APIs (e.g. this is why we added os.scandir).<br><br>A similar situation applies when it comes to glob, fnmatch, etc.<br><br></div><div>Even `shutil` will likely retain its place as a lower level procedural API behind pathlib's object-oriented facade, since raw strings are still frequently going to be easier to work with when mixing and matching Python code and native operating system shell code.<br></div><div><br></div><div>Cheers,<br></div><div>Nick.<br clear="all"></div></div><br>-- <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>