[Python-ideas] PEP: Extended stat_result (First Draft)

[Pieter Nagel]

On Mon, 2013-05-06 at 20:28 +0200, Giampaolo Rodola' wrote:

> I'm not convinced this is a good proposal.

Interesting, you seem to be the first that is against the proposal
itself, as opposed to details of the proposal.

> It duplicates a consistent amount of already existent functionality
> just for the sake of avoiding importing the stat module and using
> stat's S_IS* functions which "are ugly" because upper-cased.

Agreed, it duplicates existent functionality.

But there is precedent. When os.stat() was originally extended to return
a result object instead of a tuple, the tuple behaviour was kept, and
since then there has also been two different ways of getting at the same
data in the stat() result.

The question is whether the new way is enough of a code clarity win to
justify itself. "st.is_file()" vs "stat.S_ISREG(st.st_mode)", to my
eyes, is.

But the primary motivation is not to avoid an import and "ugly" method
names; the primary motivation is to make it easier to switch from
writing naive code that stat()s a file many times to performant code
that does stat() only once. The rest is just a happy side effect.

And the *ulterior* motivation is to reduce the need for automagic stat()
caching in PEP 428.

> -1 about these too.
> os.path provides only isfile(), isdir() and islink() because those are
> the most common and portable file types, and that's fine.
> Anything else is too specific (also *platform* specific) and does not
> deserve a new utility function in os.path.

The extent to which my additions to stat_result are "mirrored back" to
os.path is one of the least certain parts of my proposal.

And when PEP 428 is accepted, there'll be *three* places where these
methods could live, so I'll have to take that into account.

-- 
Pieter Nagel