<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 30 May 2018 at 02:38, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Honestly, despite the occasional use case(1), I'm not sure that this is a battery we need in the stdlib. Nobody seems too excited about writing the code, and when the operation is needed, shelling out to the system chown is not too onerous. (Ditto for chmod.)<br></div><div><br></div><div>(1) Not even sure that a use case was shown -- it was just shown that the operation is not necessarily useless.<br></div></div></blockquote><div><br></div>My main use cases have been in installers and test suites, but those cases have also been for Linux-specific code where shelling out to "chown -R" and "chmod -R" was an entirely acceptable alternative.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I think one of the other key points here is that "chown" and "chmod" inherently don't map at all well to the Windows filesystem access control model [1], so there's no new portability challenges arising from expecting the chown and chmod commands to be available.</div><div class="gmail_quote"></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.</div><div class="gmail_quote"><br></div><div class="gmail_quote">[1] os.chown and shutil.chown don't exist at all there, and os.chmod only 
supports setting a file to read-only - there isn't any access to user or
 group permissions.<br></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>