On 21/06/13 01:35, Benjamin Peterson wrote:
2013/6/20 Charles-François Natali <cf.nat...@gmail.com>:
2013/6/20 Thomas Wouters <tho...@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.
-1
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.
--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
