[Python-Dev] stat module in C -- what to do with stat.py? (original) (raw)
Eric V. Smith eric at trueblade.com
Fri Jun 21 14:33:43 CEST 2013
- Previous message: [Python-Dev] stat module in C -- what to do with stat.py?
- Next message: [Python-Dev] stat module in C -- what to do with stat.py?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6/21/2013 7:39 AM, Nick Coghlan wrote:
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). 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.
I was just writing up something similar. But as always, Nick said it better than me.
-- Eric.
- Previous message: [Python-Dev] stat module in C -- what to do with stat.py?
- Next message: [Python-Dev] stat module in C -- what to do with stat.py?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]