Expose file size, mode, etc from `pathlib.Path.info`

[AndersMunch]

@pf_moore

(A stronger argument, that I can’t really dispute, is that the file_attributes fields in the stat object are rarely used.)

I don’t think file attributes are well enough supported for us to draw conclusions from their lack of use.

st_file_attributes is not very discoverable: It’s not included in the repr of stat_result. And if you then want to change these flags, how do you do that? You can only set the readonly bit (chmod), and doing that uses a whole different nomenclature of posix mode bits.

[Monarch]

@barneygale

Rust’s chmod()-equivalent set_permissions() accepts a Permissions object. We’re at something of a disadvantage in that our os.chmod() and os.mkdir() functions (which are used by pathlib) accept integer permissions, even on Windows. So perhaps our WindowsPathPermissions class needs a mode() function, but it’s faked entirely from the readonly() data, very roughly:

pathlib.Path having non-cross-platform APIs is a mistake IMO, and we should be looking to reduce it instead of adding more, especially when things like chmod() silently do nothing on Windows for most input. That’s to say, I don’t think WindowsPathPermissions should have a mode() at all.

@barneygale

edit: alternatively we put it in a utility function that’s called from Path.chmod() and Path.mkdir():

def _get_posix_mode(obj):
    if isinstance(obj, PosixPathPermissions):
        return obj.mode()
    if isinstance(obj, PathPermissions):
        return 0o444 if obj.readonly() else 0o666
    if isinstance(obj, int):
        return obj
    raise TypeError(...)

I definitely like this way more. It should stay a private utility.

@barneygale

On stat():

Path.info is currently documented as a pathlib.types.PathInfo object. That protocol will eventually be helpful for people building Path-like classes for virtual filesystems, and asking those folks to create an os.stat_result-ish object is annoying/borderline nonsensical.

I agree! I don’t think stat() should be a part of the cross-platform PathInfo. It should be exclusive to the concrete PosixPathInfo.

[barneygale]

Thanks all.

If we lift the Rust Permissions API, should we use dataclasses? (I don’t see why not!)

Should PosixPermissions have a single mode field (like Rust) or separate owner, group and others fields as suggested by Nineteendo and illustrated by Neil? I’m hopelessly undecided at the moment and looking for a convincing argument one way or the other.

@Monarch

I don’t think stat() should be a part of the cross-platform PathInfo. It should be exclusive to the concrete PosixPathInfo.

I suspect we need WindowsPath.info.stat() given WindowsPath.stat() is already a thing. If it wasn’t, I’d agree!

FWIW I’ve opened a PR that adds stat().

[TeamSpen210 (Spencer Brown)]

Seperate owner/group/others fields makes more sense to me personally, since that’s semantically what they mean. Read permission for owner is the same permission as for group, just for a different user. Would make it convenient to copy from one category to another.

[ElevenPhonons]

1. I am not sure it going to be obvious that Path.info is cached by design to many users. This will have to be documented in bold and then underlined 100 times.
2. It’s adding a bit of entropy. There’s now p.is_dir() and p.info.is_dir() amongst other methods.
3. Python is so terse, I’m not sure that s = p.stat() was really a big deal. It’s explicit and obvious. Was Path.stat(cache=True) considered?
4. Internally, pathlib needs to be careful when it’s calling .info. Methods like copy and copy_info/from need to be clear why they are using a cached values.
5. The “sugar” layer of taking the output of os.stat() and translating it to more digestible form/types (e.g., Datetime, Permissions, Mode) is a stellar addition.
6. Currently, if you want the sugar-ized output of os.stat, but not the caching, you’re out of luck? I suspect people will start using Path.info for the sugar but not realizing it’s cached.
7. For the case of follow_symlinks=False, don’t you have to repeatedly call p.info.exists(follow_symlinks=False); p.info.is_dir(follow_symlinks=False)? This isn’t particularly ergonomic?

It’s a bit too late, but I would have advocated for something that is more symmetric with info and stat and that is not cached by default.

1. Path.stat(follow_symlinks=True, cache=False) to enable caching of stat call
2. Path.info(follow_symlinks=True, cache=False) with info having a sugar-ized stat output as well as is_dir() and friends that that can be optionally cached.

[barneygale]

Thanks for the helpful feedback. Not replying to everything you raised here, but do re-raise anything important that I’ve skipped over.

@ElevenPhonons

Internally, pathlib needs to be careful when it’s calling .info. Methods like copy and copy_info/from need to be clear why they are using a cached values.

Agreed. Relatedly I think we need to make pathlib invalidate the info cache whenever it writes to the filesystem (e.g. in mkdir(), chmod()). Probably we need to make it user-clearable too - something I initially resisted. I’ll log a bug about this shortly.

@ElevenPhonons

For the case of follow_symlinks=False, don’t you have to repeatedly call p.info.exists(follow_symlinks=False); p.info.is_dir(follow_symlinks=False)? This isn’t particularly ergonomic?

I don’t think that’s needed - if you need special handling for symlinks, usually it’s only necessary add a p.info.is_symlink() check before is_dir() or is_file(), or to pass follow_symlinks to just one of those methods.

@ElevenPhonons

Currently, if you want the sugar-ized output of os.stat, but not the caching, you’re out of luck? I suspect people will start using Path.info for the sugar but not realizing it’s cached.

That’s correct, at least in this proposal.

@ElevenPhonons

Path.info(follow_symlinks=True, cache=False) with info having a sugar-ized stat output as well as is_dir() and friends that that can be optionally cached.

One potential issue with that design: p.info().is_symlink() would always be false, because info() has already followed symlinks. It’s also not clear whether info() can perform filesystem access (instead of is_dir() etc? in addition?), whereas an attribute info clears that up.

[barneygale]

Q: should our PosixPermissions / WindowsPermissions objects by user-constructable? If so, do we need a Permissions superclass that morphs into a subclass upon construction (like Path), and what arguments should the initialisers accept?

[EpicWink (Laurie O)]

Having then constructable would be useful for equality tests