RetroSearch Browse

Sat Jun 22 01:58:59 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-June/127017.html

On 21Jun2013 21:39, Nick Coghlan <ncoghlan at gmail.com> wrote:
| On 21 June 2013 17:25, Victor Stinner <victor.stinner at gmail.com> wrote:
| > 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.

+1

I'm all for the C module exposing any and all of the S_* macros for
the local platform, and good with the python module (if used because
the C module isn't present, or conceivably is compiled out because
it is known broken on this platform) exposing only the portable
stuff.

At least you can detect "I don't know what to do" rather than
ploughing on mistakenly.
-- 
Cameron Simpson <cs at zip.com.au>

Ignorance is preferable to error; and he is less remote from the truth
who believes nothing, than he who believes what is wrong.
        - Thomas Jefferson

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-June/127017.html below:

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