Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
Doc/library/os.rst:os.waitid
absent on MacOS#104558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Doc/library/os.rst:os.waitid
absent on MacOS#104558
Uh oh!
There was an error while loading.Please reload this page.
Conversation
ghost commentedMay 16, 2023 • edited by ghost
Loading Uh oh!
There was an error while loading.Please reload this page.
edited by ghost
Uh oh!
There was an error while loading.Please reload this page.
b2399e2
toe7bc73d
Compare
I probably should have supported the statement that it's disabled, sorry. Lines 9191 to 9213 inc649df6
|
Uh oh!
There was an error while loading.Please reload this page.
The more interesting question here is why There's some discussion in#55021, |
You know…no it's not! If it takes 6 months to get a doc fix in and 12 months to have a policy debate and maybe change the policy and get a code fix in, I am entirely uninterested in postponing the former in favor of the latter. Open a new PR or Issue to expose Thank you. I am not as bitter as I sound. |
I don't know about other core devs, but personally I only regularly check GitHub issues for things to work on. That's mostly out of habit, but we do have a longstanding culture of having issues for almost all changes. I'm not going to argue that's a good thing, but it does explain why PRs without an issue can get lost and not get core dev attention. Anyway, I'll file an issue about exposing |
Co-authored-by: AN Long <aisk@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM
Thanks for the PR!
Uh oh!
There was an error while loading.Please reload this page.
Thanks@johnhawkinson for the PR, and@ronaldoussoren for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12. |
* Doc/library/os.rst: `os.waitid` absent on MacOS(cherry picked from commitdb1c882)Co-authored-by: John Hawkinson <jhawk@alum.mit.edu>Co-authored-by: AN Long <aisk@users.noreply.github.com>
GH-113553 is a backport of this pull request to the3.12 branch. |
* Doc/library/os.rst: `os.waitid` absent on MacOS(cherry picked from commitdb1c882)Co-authored-by: John Hawkinson <jhawk@alum.mit.edu>Co-authored-by: AN Long <aisk@users.noreply.github.com>
GH-113554 is a backport of this pull request to the3.11 branch. |
* Doc/library/os.rst: `os.waitid` absent on MacOSCo-authored-by: AN Long <aisk@users.noreply.github.com>
* Doc/library/os.rst: `os.waitid` absent on MacOSCo-authored-by: AN Long <aisk@users.noreply.github.com>
* Doc/library/os.rst: `os.waitid` absent on MacOSCo-authored-by: AN Long <aisk@users.noreply.github.com>
Uh oh!
There was an error while loading.Please reload this page.
os.waitid()
is disabled on MacOS, and that's not documented.It's not precisely clear why its disabled, and it was discussed in#55021(deeplink) which was closed without resolution.
But regardless of why, the documentation needs to clearly reflect that the function is not available.
I've followed the model of
os.fdatasync()
and noted the lack of availability in theNote
section, rather than theAvailability
section. Absent that precedent, I would have instead changedAvailability
toUnix, not Emscripten, not Macos, not WASI
, perhaps somewhat consistent withCLOCK_UPTIME_RAW
intime.rst L866.I hope this is appropriate for a PR without an Issue, but if I'm wrong, I apologize and am happy to file an Issue.
📚 Documentation preview 📚:https://cpython-previews--104558.org.readthedocs.build/