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

Steven D'Aprano steve at pearwood.info
Fri Jun 21 21:20:24 CEST 2013

On 21/06/13 01:35, Benjamin Peterson wrote:
> 2013/6/20 Charles-François Natali <cf.natali at gmail.com>:
>> 2013/6/20 Thomas Wouters <thomas at python.org>:
>>> If the .py file is going to be wrong or incomplete, why would we want to
>>> keep it -- or use it as fallback -- at all? If we're dead set on having a
>>> .py file instead of requiring it to be part of the interpreter (whichever
>>> that is, however it was built), it should be generated as part of the build
>>> process. Personally, I don't see the value in it; other implementations will
>>> need to do *something* special to use it anyway.

That's not correct. Other implementations can do exactly what CPython 3.3 does, namely just use stat.py as given. Not all implementations necessarily care about multiple platforms where stat constants are likely to change.

>> That's exactly my rationale for pushing for removal.
> +1 to nixing it.


Reading the Python source code is a very good way for beginner programmers to learn about things like this. Being able to read stat.py in Python makes a good, complementary source of information for those new to stat. Getting rid of stat.py means there's no source code to read at all, unless the user has built Python from source and kept the C source code. And even if they have, it's easy to forget how intimidating C can be to neophytes.

I'm with Nick on this one: PEP 399 already answers the question of what to do with stat.py. We keep it as a fallback, which guarantees that any Python implementation that uses the standard library is no worse off than what we have now. When available, we override the default constants with platform specific ones generated from whatever language is used by the implementation. The accuracy of those constants then becomes a matter of quality of implementation. A low quality implementation may take the lazy way out and just use the default constants, while a high quality implementation will not.

At the moment, the stat.py module contains ten small functions. Getting rid of the stat.py means that they have to be re-implemented in C/Java/RPython/etc. for every implementation. Even if the re-implementations are individually trivial, it's still a cost for no real gain. Keeping the pure Python implementation also lowers the bar for adding new functions in the future, and for documentation changes.


More information about the Python-Dev mailing list