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

Antoine Pitrou solipsis at pitrou.net
Fri Jun 21 13:45:50 CEST 2013

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 SIFMT flags, OSX/Darwin/FreeBSD > defines 0xe000 as SIFWHT (whiteout), but Solaris defines it as > SIFPORT (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.

More information about the Python-Dev mailing list