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

Nick Coghlan ncoghlan at gmail.com
Fri Jun 21 13:39:10 CEST 2013

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). 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.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list