cffi makes this kind of constant-grabbing very easy. However this is a tiny module so no problem with having a C version.
On Thu, Jun 20, 2013 at 11:04 AM, Thomas Wouters <tho...@python.org> wrote: > > > > On Thu, Jun 20, 2013 at 8:01 AM, Brett Cannon <br...@python.org> wrote: >> >> >> >> >> On Thu, Jun 20, 2013 at 10:14 AM, Eric V. Smith <e...@trueblade.com> >> wrote: >>> >>> On 6/20/2013 9:40 AM, Nick Coghlan wrote: >>> > On 20 June 2013 23:29, Christian Heimes <christ...@python.org> wrote: >>> >> Am 20.06.2013 15:21, schrieb Florent: >>> >>> we already have "_pyio.py", we could have "_pystat.py". >>> >> >>> >> Works for me. >>> > >>> > I suggest following the guidelines in PEP 399 for cross implementation >>> > compatibility of the standard library: >>> > http://www.python.org/dev/peps/pep-0399/#details >>> > >>> > 1. Keep stat.py >>> > 2. Make the C version "_stat" >>> > 3. Add the following to the end of stat.py: >>> > >>> > try: >>> > from _stat import * >>> > except ImportError: >>> > pass >>> > >>> > Run the tests with and without the C module in the test suite (again, >>> > as per PEP 399). >>> >>> Agreed with the above. >>> >>> But isn't the real problem with this module in Python the fact that the >>> constants might be wrong? I'm not sure what, if anything, we can do >>> about that. >> >> >> There isn't anything we can do beyond at least trying to provide >> reasonable defaults when something better isn't available (which is what the >> stats module has done all this time). It might make testing difficult for >> the Python code when the C code has the right values, but I don't think it's >> necessarily worth tossing out the Python code as backup. > > > 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. > > -- > Thomas Wouters <tho...@python.org> > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! > > _______________________________________________ > 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/dholth%40gmail.com > _______________________________________________ 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
