If you are doing it OO and trying to create a human-usable API, then, why the hell to stick with octal and string representations from the 1970's? path.chmod.executable could return a named-tuple-like object, with owner=True, group=False, all=False - and conversely, you could have path.chmod.owner to return (read=True, write=True, execute=True) Ad thus one could simply do: if path.chmod.owner.writable: ... On 11 January 2016 at 10:29, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Jan 11, 2016 at 11:02 PM, Ram Rachum <ram@rachum.com> wrote:
Here's my new preferred API. Assume that `path` is a `pathlib.Path` object.
Checking the chmod of the file: int(path.chmod) # Get an int 393 which in octal is 0o611 oct(path.chmod) # Get a string '0o611' str(path.chmod) # Get a string 'rw-r--r--' repr(path.chmod) # Get a string '<Chmod: rw-r--r-- / 0o611>
Modifying the chmod of the file: path.chmod(0o611) # Set chmod to 0o611 (for backward compatibility) path.chmod = 0o611 # Set chmod to 0o611 path.chmod = 393 # Set chmod to 0o611, which is 393 in decimal path.chmod = other_path.chmod # Set chmod to be the same as that of some other file path.chmod = 'rw-r--r--' # Set chmod to 0o611 path.chmod += '--x--x--x' # Add execute permission to everyone path.chmod -= '----rwx' # Remove all permissions from others
I've chosen += and -=, despite the fact they're not set operations, because Python doesn't have __inand__. On an unrelated note, maybe we should have __inand__? (I mean x ^~= y)
What do you think?
The one thing I'd do differently is call it "mode" or "permissions" rather than "chmod" (CHange MODe), and drop the callability. If you're going to do it as property assignment, making that property also be callable feels awkward (plus it'll be a pain to implement). But otherwise, yeah! Looks great!
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/