stat: provide reverse operation of stat.filemode()

[calestyo]

Feature or enhancement

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Proposal:

Hey.

stat.filemode() (which is IMO rather unfortunately named, as it doesn't return the actual file mode (bits) but just one of the string notations for it is quite helpful for many cases.

But I think the reverse function, that is converting a file mode in some string notation to the actual (binary) file mode, would also be nice to have as a convenience function.

Subsequently I'll provide a draft PR, that gives a poor man's example of how this could be done, re-using the existing stat._filemode_table.

The draft is based on what I use personally for this,… it would need to be further improved of course (see the PR, for what's missing).

But this should serve as a start so that Python core devs could decided whether they'd even want such a function at all in Pyhton.

Any opinions? :-)

Cheers,
Chris.

Linked PRs

• gh-108185: Add function to convert file mode string to binary file mode #108186

[picnixz]

Is there a canonical representation for this? if there is none, I'm afraid I would rather reject this (it wouldn't be nonsensical to have it in a 3rd party library, but for it to be in the standard library, I would rather have a canonical representation or a representation that is used by any of the common standards if any)

[calestyo]

@picnixz what exactly do you mean by "canonical representation"?

Both input formats (the octal notation and the letter notation as used by chmod) are well defined by POSIX and user in many places in the Linux/Unix world.

[picnixz]

Ah my bad, I missed the "re-using the existing stat._filemode_table." part. I thought you wanted to reuse some non-canonical definition. I'm fine with that.

[calestyo]

@picnixz Then it's mainly whether others agree that such function would make sense to be added, and if so... the open point's in my PR.

Most of them were simply design questions where where I guess some core dev should simply say what he thinks would be the most pythonic way.

[picnixz]

If you want to ask the opinion of others dev, please open a discourse topic instead of an issue. Issues are usually for features that are accepted and don't need prior discussions (or features that really make sense because we're lacking them). Personally, I am more likely to convert it from mode to string rather than string to mode so I wouldn't use it.