[Python-Dev] stat module in C -- what to do with stat.py?

[Antoine Pitrou]

Le Fri, 21 Jun 2013 21:39:10 +1000,
Nick Coghlan <ncoghlan at gmail.com> a écrit :

> On 21 June 2013 17:25, Victor Stinner <victor.stinner at gmail.com>
> wrote:
> > 2013/6/21 Nick Coghlan <ncoghlan at gmail.com>:
> >> Because practicality beats purity. This "wrong" Python code has
> >> been good enough for all Python version up until 3.4, it makes
> >> sense to keep it as a fallback instead of throwing it away.
> >
> > How do you plan to handle the following case in Python?
> >
> > "Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD
> > defines 0xe000 as S_IFWHT (whiteout), but Solaris defines it as
> > S_IFPORT (event port)."
> >
> > We may keep the Python module if it is kept unchanged, but the
> > Python and C modules should have the same public API (the C module
> > should not have more features).
> 
> I think it's OK to expose additional platform specific features in the
> C version, and have them fail cleanly with the pure Python version
> (rather than silently giving the wrong answer).

PEP 399 says we don't do it:

"Acting as a drop-in replacement also dictates that no public API be
provided in accelerated code that does not exist in the pure Python
code. Without this requirement people could accidentally come to rely
on a detail in the accelerated code which is not made available to
other VMs that use the pure Python implementation."

> What's not OK is for
> the standard library to regress for other implementations just because
> we added a C implementation for the benefit of CPython. That's exactly
> the kind of thing PEP 399 says we *won't* do.

For me, PEP 399 should not be considered a requirement but a guideline.
stat.py is algorithmically trivial and I don't think it saves much work
for authors of third-party Python implementations.

Regards

Antoine.